DEV 環境で Java 1.6 アプリケーションの負荷テストを行っています。JVM ヒープ割り当ては 2Gb、-Xms2048m -Xmx2048m です。負荷テストでは、アプリはスムーズに動作し、1.25Gb を超えるヒープを使用することはなく、ガベージ コレクションはまったく正常です。
私たちの UAT 環境では、同じパラメーターを使用して負荷テストを実行します。唯一の違いは JVM で、4Gb、-Xms4096m -Xmx4096m が割り当てられています。それ以外のハードウェアは DEV とまったく同じです。しかし負荷テスト中のパフォーマンスは恐るべきもので、アプリはほぼすべてのヒープを消費し、ガベージ コレクションが猛威を振るいます。
これらのテストを何度も実行し、パフォーマンスに影響を与える可能性のあるすべての症状を排除しましたが、結果は同じです. これはどのような状況で起こり得るのでしょうか？
本番環境と UAT 環境では、アプリケーションに何か違いがあります。
症状から判断すると、(IMO) ハードウェア、オペレーティング システムのパフォーマンス チューニング、または JVM バージョンの違いである可能性は低いです。言うまでもなく、これはアプリケーションがより多くのメモリを持っていることが原因である可能性は低いです。
(あなたのアプリケーションが奇妙なことをするかもしれないということは考えられないことではありません...最大ヒープサイズに基づいていくつかのデータ構造のサイジングを行い、計算を間違えるなどです。しかし、私はあなたがその可能性を認識していると思うので、今のところそれを無視しましょう.)
OS環境の違いが関係していると思われます。たとえば、OS や一部のアプリケーションのバージョンの違い、ネットワークの違い、ロケールの違いなどです。しかし、肝心なのは、UAT で実行したときにアプリケーションにメモリ リークがあることは 99% 確実であり、そのメモリ リークがヒープ メモリを消費し、GC を過負荷にしているということです。
私のアドバイスは、これをストレージ リークの問題として扱い、標準的なツールや手法を使用して問題の原因を突き止めることです。その過程で、これが UAT でのみ発生する理由を理解できる可能性が高くなります。
これらのマシンの両方でヒープ ダンプを分析し、これら 2 つの環境で何がヒープを異なる方法で消費しているかを理解することは価値があります。ヒストグラムが役立ちます。
原因はガベージ コレクションである可能性があります。通常の「stop-the-world」タイプのコレクションでは、いくつかのパフォーマンスの問題が発生しました。サーバー ソフトウェアは非常に低速で実行されていましたが、サーバーの負荷も低かったです。最終的に、特定のシナリオ (大量のガベージを生成する操作) で常に実行されているソフトウェア全体を保持している単一の「世界を止める」ガベージ コレクター スレッドがあることがわかりました。
コンカレント ガベージ コレクションに移行したことで、起動パラメータの問題が軽減されました-XX:+UseParallelOldGC -XX:ParallelGCThreads=8。テストと本番環境では 2GB ヒープのみを使用していましたが、ヒープが大きくなると GC にかかる時間が長くなることも注目に値します (ソフトウェアが実際にすべてを使用しない場合でも)。
Java SE 6 HotSpot[tm] Virtual Machine Garbage Collection Tuningから、さまざまなガベージ コレクターのオプションとチューニングについて詳しくお読みください。
また、この質問の回答は、いくつかの助けになる可能性があります: Java very large heapsized。