2017-01-12 5 views
0

ドッキング・コンテナのそれぞれに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 

(直線的に増加メモリ)別の画像を表示します。私はそれより長く走っていませんが、直線的に増加するのではなく、これがプラトーに達するはずです。

+0

問題はドッカーの統計情報そのものであるようです:https://github.com/docker/docker/issues/10824この問題はクローズされているとタグ付けされています。私は修正を含むドッカーバージョン1.12.5を使用しています。その他の未解決の問題は参照されていますが、実際には私の環境には当てはまりません。 – Anu

+0

なぜこれが明確でないかについてのコメントなしでdownvotedされましたか? – Anu

+0

これはあなたの質問に対する答えではありませんが、私は数ヶ月前に同様の問題があることを覚えています。私はリソース監視のために 'dstat'に切り替えました。 – mattes

答えて

1

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はこのメソッドの影響を受け、正確には のメモリ(およびスワップ)使用量の値を表示しません。これは効率的な アクセスのためのファズ値です。 にもっと正確なメモリ使用量を知りたい場合は、 memory.stat(5.2参照)でRSS + CACHE(+ SWAP)値を使用する必要があります。

ページキャッシュとRESはメモリusage_in_bytes番号に含まれています。したがって、コンテナにファイルI/Oがある場合、メモリ使用量の統計量が増加します。しかし、コンテナの場合、最大使用量に達すると、使用されていないメモリの一部が再利用されます。したがって、コンテナにメモリ制限を追加すると、メモリが再利用され、制限値に達すると使用されることがわかりました。再利用するメモリがなく、OOMエラーが発生しない限り、コンテナプロセスは強制終了されません。ドッカーの統計情報に表示されている数値に関係する人にとっては、簡単な方法はcgroupsで利用可能な詳細な統計を/ sys/fs/cgroup/memory/docker // で確認することです。 .statsまたは他のメモリ。*ファイル。あなたがこの参照従うことによって、あなたがそうすることができ、「ドッキングウィンドウの実行」コマンドでドッキングウィンドウコンテナによって使用されるリソースを制限する場合

:私はドッカ-コンを使用しておりますのでhttps://docs.docker.com/engine/admin/resource_constraints/

を、私は追加することによって、それをやりました私のドッカーのライン - 作成する。私は制限したいサービスの下YMLファイル:

mem_limit:mはメガバイトの略32メートル

+0

systemd-cgtop -mは、ドッカーの統計情報と同じメモリを表示します。 cgroupsメトリックとdocker統計情報をリンクするもう1つの証明と、cgroupsメトリクスのmemory.usage_in_bytesへのページキャッシュインクルード – Anu

+0

私はそれが問題[リンク](https://github.com/docker/docker/issues/10824)まだ解決されていません。 – prvn

+0

はい@prvn。誤解を招くような情報(キャッシュを含む)が表示されます。それを修正することについて話がありますが、まだ完了しておらず、誤って閉じています。 – Anu

関連する問題