問題タブ [kubernetes-metrics]

の関係を理解し​​ようとしています。

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"}

約 18 ノードの Kubernetes クラスターがあり、4 コアと 16G RAM を備えたものはほとんどなく、16 コアと 64G RAM を備えたものもほとんどなく、クラスター上で約 25 ～ 30 個のアプリケーションが実行されています。

各アプリケーションは、リクエストと制限パラメーターで構成され、約 2 ～ 3 コアと 4 ～ 8G RAM で、各アプリケーションに割り当てられます。

現在のクラスター内に残っているコア/RAM の数を示す現在の使用率レポートを取得するにはどうすればよいですか? 新しいアプリケーションをデプロイする前。

以下のコマンドを使用してみました：

これらは私に正確なノーを与えていません。残っているコアまたはラムの。

これにつながるものは非常に役立ちます。

注: バージョン 1.19 の Kubernetes を使用しています。