我编写了一个golang应用程序，运行在我的每个docker容器中。它通过tcp和udp使用protobufs进行通信，我使用Hashicorp的memberlist库来发现网络中的每个容器。在docker统计数据中，我看到内存使用率呈线性增长，所以我正在努力查找应用程序中的任何漏洞。
由于它是一个持续运行的应用程序，我使用http-prof来检查任何一个容器中的活动应用程序。我看到了运行时。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/propf/goroutine验证是否没有发生goroutine泄漏？debug=1
请评论为什么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/)
如果您阅读了"过时但有用"的文档(https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt)上面写着
5.5 usage_in_bytes
为了提高效率，与其他内核组件一样，内存cgroup使用优化以避免不必要的缓存线错误共享。usage_in_bytes受该方法影响，不显示"精确"内存(和交换)使用的值，这是一个模糊值通道(当然，在必要的时候，它是同步的。)如果你想要知道更精确的内存使用情况，应该在中使用RSS+CACHE(+SWAP)值memory.stat(见5.2).
页面缓存和RES包含在内存usage_in_bytes数中。因此，如果容器具有文件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-compase.yml文件中添加了一行：
mem_limit:32m
其中m代表兆字节。