ドッキング・コンテナのそれぞれにgolangアプリケーションを実行しました。 tcpとudpを介してprotobufsを使ってお互いに通信し、Hashicorpのメンバーリストライブラリを使用して、ネットワーク内の各コンテナを検出します。 ドッカーの統計情報では、メモリ使用量が直線的に増加しているため、アプリケーションでリークを見つけようとしています。「メモリ使用量」メトリック:Goツールpprofとドッカーの統計
実行中のアプリケーションであるため、http pprofを使用して、いずれかのコンテナ内のライブアプリケーションをチェックしています。 docker statsが直線的に増加していても、runtime.MemStats.sysは一定です。 --inuse_spaceは約1MBで、--alloc_space ofcourseは時間とともに増加し続けます。ここalloc_spaceのサンプルです:
[email protected]:/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を使用して起こっていないことを確認することができました://:?= 1
8080 /デバッグ/ pprof /ゴルーチンデバッグにコメントしてくださいなぜドッキングウィンドウの統計私は一晩、それを実行している場合、このメモリは250メガバイトの周りにbloats
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
(直線的に増加メモリ)別の画像を表示します。私はそれより長く走っていませんが、直線的に増加するのではなく、これがプラトーに達するはずです。
問題はドッカーの統計情報そのものであるようです:https://github.com/docker/docker/issues/10824この問題はクローズされているとタグ付けされています。私は修正を含むドッカーバージョン1.12.5を使用しています。その他の未解決の問題は参照されていますが、実際には私の環境には当てはまりません。 – Anu
なぜこれが明確でないかについてのコメントなしでdownvotedされましたか? – Anu
これはあなたの質問に対する答えではありませんが、私は数ヶ月前に同様の問題があることを覚えています。私はリソース監視のために 'dstat'に切り替えました。 – mattes