の関係を理解しようとしています。
container_memory_working_set_bytes vs process_resident_memory_bytes vs total_rss (container_memory_rss) + file_mappedにより、OOM の可能性を警告するためのシステムをより適切に装備できます。
コンテナ/ポッドがGoで書かれたコンパイル済みプログラムを実行する単一のプロセスを実行している場合、それは私の理解に反しているようです(これは今私を困惑させています) 。
との差container_memory_working_set_bytesが非常に大きい (ほぼ 10 倍以上)のはなぜですか?process_resident_memory_bytes
container_memory_working_set_bytesまた、ここでとの関係は奇妙です。ここcontainer_memory_rss + file_mappedを読んだ後、私は予期していませんでした
匿名およびスワップ キャッシュ メモリの合計量 (transparent hugepages を含む)。これは、memory.status ファイルの total_rss の値と同じです。これを、実際の常駐セット サイズまたは cgroup によって使用される物理メモリの量と混同しないでください。rss + file_mapped は、cgroup の常駐セット サイズを示します。スワップアウトされたメモリは含まれません。これらのライブラリのページが実際にメモリ内にある限り、共有ライブラリのメモリは含まれます。すべてのスタックおよびヒープ メモリが含まれます。
したがってcgroup、常駐セットの合計サイズは、この値が特定の cgroup で実行されているコンテナーのrss + file_mapped場合よりもどのように小さいかですcontainer_working_set_bytes
これは、私が正しくないというこの統計で何かを感じさせます.
以下は、上記のグラフを作成するために使用される PROMQL です。
- process_resident_memory_bytes{container="sftp-downloader"}
- container_memory_working_set_bytes{container="sftp-downloader"}
- go_memstats_heap_alloc_bytes{container="sftp-downloader"}
- container_memory_mapped_file{container="sftp-downloader"} + container_memory_rss{container="sftp-downloader"}