クラウドネイティブのコンテキストで JVM メモリを構成する方法

背景

少し前に、ビジネス開発チームから、アプリケーションのメモリ使用量が非常に高く、頻繁に再起動が発生しているとの報告があり、何が起こっているのか調べてほしいと依頼されました。

これまでこの問題にはあまり注目していなかったので、調査と分析のプロセスを記録しておきます。

まず、監視パネルで Pod の監視を確認しました。

確かにほぼ満杯であることがわかりましたが、アプリケーションの JVM 使用率を確認すると、約 30% しかありませんでした。これは、JVM OOM の原因となったのはアプリケーション メモリがいっぱいだったのではなく、Pod メモリがいっぱいだったために Pod メモリ オーバーフローが発生し、k8s によって強制終了されたことを示しています。

アプリケーションのレプリカ数を維持するために、k8s は Pod を再起動する必要があるため、一定時間実行した後にアプリケーションが再起動されるようです。

このアプリケーションは JVM 8G で構成されており、コンテナは 16G のメモリを要求するため、Pod のメモリ使用量は約 50% になるようです。

コンテナの原理

この問題を解決する前に、まずコンテナの動作原理について簡単に理解しておきましょう。なぜなら、k8s ではすべてのアプリケーションがコンテナ内で実行され、コンテナは基本的にホスト マシン上で実行される通常のアプリケーションだからです。

しかし、Docker を使用すると、各コンテナで起動されたアプリケーションが互いに干渉せず、ファイルシステム、ネットワーク、CPU、メモリが完全に分離され、まるで異なるサーバーで 2 つのアプリケーションが実行されているように感じられます。

実際のところ、これはブラックテクノロジーではありません。 Linux はバージョン 2.6.x 以降、長い間namespace分離をサポートしてきました。 namespaceを使用すると、2 つのプロセスを完全に分離できます。

単にリソースを分離するだけでは不十分で、CPU、メモリ、ディスク、帯域幅などのリソースの使用を制限することも必要です。これはcgroupsを使用して設定することもできます。

特定のプロセスのリソースを制限することができます。たとえば、ホストマシンに 4 コアの CPU と 8G のメモリがある場合、他のコンテナを保護するには、コンテナを 1 コアの CPU、2G のメモリという上限で構成する必要があります。

この図は、コンテナ テクノロジーにおける名前空間と cgroup の役割を明確に示しています。要するに：

• 名前空間は分離を担う
• cgroupは制限する責任がある

k8s にも対応する引き出しがあります:

 resources: requests: memory: 1024Mi cpu: 0.1 limits: memory: 1024Mi cpu: 4

このリソース リストは、アプリケーションがコンテナーに少なくとも 1 つの 0.1 コアと 1024M のリソースを割り当てる必要があり、最大 CPU 制限が 4 コアであることを示しています。

異なるOOM

この問題に戻ると、コンテナに OOM があり、それが k8s によって再起動されることを確認できます。これは制限を設定する目的でもあります。

k8s メモリ オーバーフローによりコンテナが終了した場合、終了コード 137 のイベント ログが表示されます。

アプリケーションの JVM メモリ構成はコンテナ構成サイズと同じであるため、両方とも 8 GB ですが、Java アプリケーションにはオフヒープ メモリなどの JVM 管理外のメモリも含まれており、コンテナ メモリ サイズが簡単に 8 GB の制限を超え、コンテナ メモリ オーバーフローが発生する可能性があります。

クラウドネイティブバックグラウンドの最適化

アプリケーション自体は多くのメモリを使用しないため、ヒープメモリを 4 GB に制限することをお勧めします。これにより、コンテナのメモリ制限を回避し、問題を解決できます。

もちろん、後でアプリケーション構成の列にも提案を追加します。JVM 構成はコンテナ制限の 2/3 未満にし、メモリを予約することをお勧めします。

実際のところ、本質は開発モデルが変わっていないということです。従来の Java アプリケーション開発モデルでは、すべてのアプリケーションが大容量メモリを搭載した仮想マシンにデプロイされていたため、コンテナのメモリ サイズさえもわからず、コンテナ メモリの制限を認識することができませんでした。

これは、追加の JVM が存在する Java アプリケーションでは特に顕著になる可能性があります。古いバージョンの JDK でも、ヒープ メモリ サイズが設定されていない場合、コンテナーのメモリ制限を感知できず、自動生成された Xmx がコンテナーのメモリ サイズよりも大きくなり、OOM が発生します。