16Gb の RAM、8 コア プロセッサ、およびすべて CentOS リリース 5.2 (Final) で実行されている Java 1.6 を搭載したマシンで、メモリを集中的に使用するアプリを実行しています。正確な JVM の詳細は次のとおりです。
java version "1.6.0_10"
Java(TM) SE Runtime Environment (build 1.6.0_10-b33)
Java HotSpot(TM) 64-Bit Server VM (build 11.0-b15, mixed mode)
次のコマンド ライン オプションを使用してアプリを起動しています。
java -XX:+UseConcMarkSweepGC -verbose:gc -server -Xmx10g -Xms10g ...
私のアプリケーションは JSON-RPC API を公開しており、私の目標は 25 ミリ秒以内にリクエストに応答することです。残念ながら、最大で 1 秒以上の遅延が見られます。これはガベージ コレクションが原因のようです。より長い例のいくつかを次に示します。
[GC 4592788K->4462162K(10468736K), 1.3606660 secs]
[GC 5881547K->5768559K(10468736K), 1.2559860 secs]
[GC 6045823K->5914115K(10468736K), 1.3250050 secs]
これらの各ガベージ コレクション イベントには、示されているガベージ コレクションの長さとほぼ同じ時間 (数ミリ秒以内) の API 応答の遅延が伴いました。
いくつかの典型的な例を次に示します (これらはすべて数秒以内に生成されました)。
[GC 3373764K->3336654K(10468736K), 0.6677560 secs]
[GC 3472974K->3427592K(10468736K), 0.5059650 secs]
[GC 3563912K->3517273K(10468736K), 0.6844440 secs]
[GC 3622292K->3589011K(10468736K), 0.4528480 secs]
問題は、UseConcMarkSweepGC がこれを回避するか、少なくとも非常にまれにするだろうと私が考えたことです。反対に、100 ミリ秒を超える遅延はほぼ 1 分に 1 回以上発生しています (ただし、1 秒を超える遅延はかなりまれであり、おそらく 10 分または 15 分に 1 回です)。
もう 1 つのことは、スレッドが一時停止されるのは FULL GC だけだと思っていましたが、これらは完全な GC ではないようです。
ほとんどのメモリは、ソフト参照を利用する LRU メモリ キャッシュによって占められていることに注意してください。
任意の支援やアドバイスをいただければ幸いです。