Tomcat にデプロイされた非常に大きな Java アプリケーションがあるとします。数週間のうちに、サーバーのメモリが不足し、アプリケーションのパフォーマンスが低下し、サーバーを再起動する必要があります。
明らかに、アプリケーションには修正が必要なメモリ リークがいくつかあります。
私の質問は..アプリケーションが別のサーバーにデプロイされた場合、メモリ使用率に変化はありますか?
質問する
580 次
2 に答える
3
確かに、アプリケーション サーバーによって提供されるサービスのメモリ使用率はさまざまです。また、サーバーに固有の VM が含まれている場合 (つまり、あるサーバーで J9 または JRockit を使用し、別のサーバーで Oracle の JVM を使用している場合) は、違います。重要な関連領域の 1 つは、クラスの読み込みです。一部のアプリ サーバーは、管理に関して他のアプリ サーバーよりも優れた動作をします。構成の変更後にアプリケーションをウォーム スタートすると、一部のサーバー/VM の組み合わせでクラスの読み込みの問題が原因で、重大なメモリ リークが発生する可能性があります。
しかし、これらのどれも、リークするアプリケーションで実際に役立つものではありません. サーバーではなくメモリを使用するプログラムであるため、サーバーを変更してもほとんど影響はありません。
于 2012-05-09T02:25:19.877 に答える
2
おそらくメモリ使用率にはわずかな違いがありますが、それはサーブレット コンテナ間でフットプリントが異なる分だけです。コンテナでメモリ リークが発生する可能性もわずかにありますが、これは疑わしいものです。
最も可能性の高い問題は、アプリケーションでメモリ リークが発生していることです。いずれにせよ、迅速な修正よりも原因の方が重要です。「新しい」コンテナがたまたま 1 週間以上続く場合などはどうしますか? 問題を動かしても解決することはめったにありません...
問題の原因を特定するには、アプリケーションのヒープ メモリの分析を開始する必要があります。アプリケーションが OOME でクラッシュする場合は、これを JVM 引数に追加できます。
-XX:-HeapDumpOnOutOfMemoryError
コンテナを手動で再起動するまでパフォーマンスが低下している場合は、定期的なヒープ ダンプをトリガーするルーチンに入る必要があります。多くの場合、ダンプのタイムラインが最も役立ちます。時間の経過とともにどのオブジェクト ストアが大きくなっていくかがわかります。
これを行うには、ヒープ分析ツールが必要です。
JHatまたはIBM Heap Analyzerまたはお好みのもの:)
この質問も参照してください。
アップデート：
そして、これは（明らかな理由で）役立つかもしれません：
于 2012-05-10T09:20:25.623 に答える