"Memory used" 指标:Go 工具 pprof 与 docker 统计数据
"Memory used" metric: Go tool pprof vs docker stats
我在每个 docker 容器中编写了一个 golang 应用程序 运行ning。它使用 protobufs 通过 tcp 和 udp 相互通信,我使用 Hashicorp 的成员列表库来发现我网络中的每个容器。
在 docker 统计信息中,我看到内存使用量呈线性增加,因此我试图找出我的应用程序中的任何泄漏。
由于它是一个保持 运行ning 的应用程序,我正在使用 http pprof 检查任何一个容器中的实时应用程序。
我看到 runtime.MemStats.sys 是恒定的,即使 docker 统计数据是线性增加的。
我的 --inuse_space 大约是 1MB,当然 --alloc_space 随着时间的推移不断增加。这是 alloc_space 的示例:
root@n3:/app# go tool pprof --alloc_space main http://localhost:8080/debug/pprof/heap
Fetching profile from http://localhost:8080/debug/pprof/heap
Saved profile in /root/pprof/pprof.main.localhost:8080.alloc_objects.alloc_space.005.pb.gz
Entering interactive mode (type "help" for commands)
(pprof) top --cum
1024.11kB of 10298.19kB total ( 9.94%)
Dropped 8 nodes (cum <= 51.49kB)
Showing top 10 nodes out of 34 (cum >= 1536.07kB)
flat flat% sum% cum cum%
0 0% 0% 10298.19kB 100% runtime.goexit
0 0% 0% 6144.48kB 59.67% main.Listener
0 0% 0% 3072.20kB 29.83% github.com/golang/protobuf/proto.Unmarshal
512.10kB 4.97% 4.97% 3072.20kB 29.83% github.com/golang/protobuf/proto.UnmarshalMerge
0 0% 4.97% 2560.17kB 24.86% github.com/hashicorp/memberlist.(*Memberlist).triggerFunc
0 0% 4.97% 2560.10kB 24.86% github.com/golang/protobuf/proto.(*Buffer).Unmarshal
0 0% 4.97% 2560.10kB 24.86% github.com/golang/protobuf/proto.(*Buffer).dec_struct_message
0 0% 4.97% 2560.10kB 24.86% github.com/golang/protobuf/proto.(*Buffer).unmarshalType
512.01kB 4.97% 9.94% 2048.23kB 19.89% main.SaveAsFile
0 0% 9.94% 1536.07kB 14.92% reflect.New
(pprof) list main.Listener
Total: 10.06MB
ROUTINE ======================== main.Listener in /app/listener.go
0 6MB (flat, cum) 59.67% of Total
. . 24: l.SetReadBuffer(MaxDatagramSize)
. . 25: defer l.Close()
. . 26: m := new(NewMsg)
. . 27: b := make([]byte, MaxDatagramSize)
. . 28: for {
. 512.02kB 29: n, src, err := l.ReadFromUDP(b)
. . 30: if err != nil {
. . 31: log.Fatal("ReadFromUDP failed:", err)
. . 32: }
. 512.02kB 33: log.Println(n, "bytes read from", src)
. . 34: //TODO remove later. For testing Fetcher only
. . 35: if rand.Intn(100) < MCastDropPercent {
. . 36: continue
. . 37: }
. 3MB 38: err = proto.Unmarshal(b[:n], m)
. . 39: if err != nil {
. . 40: log.Fatal("protobuf Unmarshal failed", err)
. . 41: }
. . 42: id := m.GetHead().GetMsgId()
. . 43: log.Println("CONFIG-UPDATE-RECEIVED { \"update_id\" =", id, "}")
. . 44: //TODO check whether value already exists in store?
. . 45: store.Add(id)
. 2MB 46: SaveAsFile(id, b[:n], StoreDir)
. . 47: m.Reset()
. . 48: }
. . 49:}
(pprof)
我已经能够使用 http://:8080/debug/pprof/goroutine?debug=1
验证没有 goroutine 泄漏发生
请评论为什么 docker 统计数据显示不同的图片(内存线性增加)
CONTAINER CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
n3 0.13% 19.73 MiB / 31.36 GiB 0.06% 595 kB / 806 B 0 B / 73.73 kB 14
如果我 运行 它过夜,这个内存会膨胀到大约 250MB。我还没有 运行 它比那更长,但我觉得这应该达到一个平台而不是线性增加
docker stats 显示来自 cgroups 的内存使用统计信息。 (参考:https://docs.docker.com/engine/admin/runmetrics/)
如果您阅读 "outdated but useful" 文档 (https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt),它会说
5.5 usage_in_bytes
For efficiency, as other kernel components, memory cgroup uses some
optimization to avoid unnecessary cacheline false sharing.
usage_in_bytes is affected by the method and doesn't show 'exact'
value of memory (and swap) usage, it's a fuzz value for efficient
access. (Of course, when necessary, it's synchronized.) If you want to
know more exact memory usage, you should use RSS+CACHE(+SWAP) value in
memory.stat(see 5.2).
Page Cache 和RES 都包含在内存usage_in_bytes 中。所以如果容器有 File I/O,内存使用统计会增加。但是,对于容器,如果使用量达到最大限制,它会回收一些未使用的内存。因此,当我向我的容器添加内存限制时,我可以观察到内存在达到限制时被回收和使用。除非没有内存可回收并且发生 OOM 错误,否则容器进程不会被终止。对于关心 docker 统计数据中显示的数字的任何人,简单的方法是检查路径中 cgroups 中可用的详细统计数据:/sys/fs/cgroup/memory/docker//
这会在 memory.stats 或其他 memory.* 文件中详细显示所有内存指标。
如果您想在 "docker run" 命令中限制 docker 容器使用的资源,您可以按照以下参考进行操作:https://docs.docker.com/engine/admin/resource_constraints/
因为我使用的是 docker-compose,所以我在我的 docker-compose.yml 文件中添加了一行我想限制的服务:
mem_limit: 32m
其中 m 代表兆字节。
我在每个 docker 容器中编写了一个 golang 应用程序 运行ning。它使用 protobufs 通过 tcp 和 udp 相互通信,我使用 Hashicorp 的成员列表库来发现我网络中的每个容器。 在 docker 统计信息中,我看到内存使用量呈线性增加,因此我试图找出我的应用程序中的任何泄漏。
由于它是一个保持 运行ning 的应用程序,我正在使用 http pprof 检查任何一个容器中的实时应用程序。 我看到 runtime.MemStats.sys 是恒定的,即使 docker 统计数据是线性增加的。 我的 --inuse_space 大约是 1MB,当然 --alloc_space 随着时间的推移不断增加。这是 alloc_space 的示例:
root@n3:/app# go tool pprof --alloc_space main http://localhost:8080/debug/pprof/heap
Fetching profile from http://localhost:8080/debug/pprof/heap
Saved profile in /root/pprof/pprof.main.localhost:8080.alloc_objects.alloc_space.005.pb.gz
Entering interactive mode (type "help" for commands)
(pprof) top --cum
1024.11kB of 10298.19kB total ( 9.94%)
Dropped 8 nodes (cum <= 51.49kB)
Showing top 10 nodes out of 34 (cum >= 1536.07kB)
flat flat% sum% cum cum%
0 0% 0% 10298.19kB 100% runtime.goexit
0 0% 0% 6144.48kB 59.67% main.Listener
0 0% 0% 3072.20kB 29.83% github.com/golang/protobuf/proto.Unmarshal
512.10kB 4.97% 4.97% 3072.20kB 29.83% github.com/golang/protobuf/proto.UnmarshalMerge
0 0% 4.97% 2560.17kB 24.86% github.com/hashicorp/memberlist.(*Memberlist).triggerFunc
0 0% 4.97% 2560.10kB 24.86% github.com/golang/protobuf/proto.(*Buffer).Unmarshal
0 0% 4.97% 2560.10kB 24.86% github.com/golang/protobuf/proto.(*Buffer).dec_struct_message
0 0% 4.97% 2560.10kB 24.86% github.com/golang/protobuf/proto.(*Buffer).unmarshalType
512.01kB 4.97% 9.94% 2048.23kB 19.89% main.SaveAsFile
0 0% 9.94% 1536.07kB 14.92% reflect.New
(pprof) list main.Listener
Total: 10.06MB
ROUTINE ======================== main.Listener in /app/listener.go
0 6MB (flat, cum) 59.67% of Total
. . 24: l.SetReadBuffer(MaxDatagramSize)
. . 25: defer l.Close()
. . 26: m := new(NewMsg)
. . 27: b := make([]byte, MaxDatagramSize)
. . 28: for {
. 512.02kB 29: n, src, err := l.ReadFromUDP(b)
. . 30: if err != nil {
. . 31: log.Fatal("ReadFromUDP failed:", err)
. . 32: }
. 512.02kB 33: log.Println(n, "bytes read from", src)
. . 34: //TODO remove later. For testing Fetcher only
. . 35: if rand.Intn(100) < MCastDropPercent {
. . 36: continue
. . 37: }
. 3MB 38: err = proto.Unmarshal(b[:n], m)
. . 39: if err != nil {
. . 40: log.Fatal("protobuf Unmarshal failed", err)
. . 41: }
. . 42: id := m.GetHead().GetMsgId()
. . 43: log.Println("CONFIG-UPDATE-RECEIVED { \"update_id\" =", id, "}")
. . 44: //TODO check whether value already exists in store?
. . 45: store.Add(id)
. 2MB 46: SaveAsFile(id, b[:n], StoreDir)
. . 47: m.Reset()
. . 48: }
. . 49:}
(pprof)
我已经能够使用 http://:8080/debug/pprof/goroutine?debug=1
验证没有 goroutine 泄漏发生请评论为什么 docker 统计数据显示不同的图片(内存线性增加)
CONTAINER CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
n3 0.13% 19.73 MiB / 31.36 GiB 0.06% 595 kB / 806 B 0 B / 73.73 kB 14
如果我 运行 它过夜,这个内存会膨胀到大约 250MB。我还没有 运行 它比那更长,但我觉得这应该达到一个平台而不是线性增加
docker stats 显示来自 cgroups 的内存使用统计信息。 (参考:https://docs.docker.com/engine/admin/runmetrics/)
如果您阅读 "outdated but useful" 文档 (https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt),它会说
5.5 usage_in_bytes
For efficiency, as other kernel components, memory cgroup uses some optimization to avoid unnecessary cacheline false sharing. usage_in_bytes is affected by the method and doesn't show 'exact' value of memory (and swap) usage, it's a fuzz value for efficient access. (Of course, when necessary, it's synchronized.) If you want to know more exact memory usage, you should use RSS+CACHE(+SWAP) value in memory.stat(see 5.2).
Page Cache 和RES 都包含在内存usage_in_bytes 中。所以如果容器有 File I/O,内存使用统计会增加。但是,对于容器,如果使用量达到最大限制,它会回收一些未使用的内存。因此,当我向我的容器添加内存限制时,我可以观察到内存在达到限制时被回收和使用。除非没有内存可回收并且发生 OOM 错误,否则容器进程不会被终止。对于关心 docker 统计数据中显示的数字的任何人,简单的方法是检查路径中 cgroups 中可用的详细统计数据:/sys/fs/cgroup/memory/docker// 这会在 memory.stats 或其他 memory.* 文件中详细显示所有内存指标。
如果您想在 "docker run" 命令中限制 docker 容器使用的资源,您可以按照以下参考进行操作:https://docs.docker.com/engine/admin/resource_constraints/
因为我使用的是 docker-compose,所以我在我的 docker-compose.yml 文件中添加了一行我想限制的服务:
mem_limit: 32m
其中 m 代表兆字节。