11

Javaで実行されているカウンターをヒットしました。24 時間稼働し、1 秒間に約 100 回ヒットします。日中、GC 処理時間は 20 ～ 60 ミリ秒から 10000 ～ 60000 ミリ秒までゆっくりと上昇し、その後 20 ～ 60 ミリ秒に低下します。このようなパターンが時々繰り返されます。GC ログから、参照オブジェクト (Ref Proc) の処理にほとんどすべての時間 GC が費やされていることがわかりました。では、このような長い GC 時間の原因は何でしょうか?

Server: Amazon EC2 m1.small
OS: Ubuntu 10.04.3 LTS
Java: Oracle 1.7.0_07

GC ログの例:

2012-09-13T16:51:20.091+0400: 167239.936: [GC pause (young), 62.58395400 secs]
...
[Other: 62489.7 ms]
    [Choose CSet:   0.0 ms]
    [Ref Proc: 62433.9 ms]
    [Ref Enq:   0.0 ms]
    [Free CSet:   0.7 ms]
[Eden: 200M(200M)->0B(199M) Survivors: 4096K->5120K Heap: 578M(1024M)->380M(1024M)]

時間 - 「Ref Proc」グラフ:

09:37:59 - 242.4 ms
09:38:50 - 226.0 ms
09:39:00 - 83.6 ms
...
11:45:22 - 451.8 ms
11:46:04 - 489.3 ms
11:46:46 - 505.6 ms
...
14:05:40 - 1027.3 ms
14:06:01 - 796.6 ms
14:06:35 - 1064.0 ms
...
15:44:32 - 1920.4 ms
15:45:04 - 2116.7 ms
15:45:39 - 2196.8 ms
...
16:19:07 - 3983.3 ms
16:19:43 - 4494.9 ms
16:20:16 - 4065.2 ms
...
16:33:11 - 7690.1 ms
16:33:50 - 8501.4 ms
16:34:28 - 8059.3 ms
...
16:47:14 - 51378.6 ms
16:49:11 - 57529.2 ms
16:51:20 - 62433.9 ms
16:53:00 - 46.1 ms
16:53:30 - 45.5 ms
16:54:03 - 45.0 ms
...
16:54:38 - 57.0 ms
16:55:09 - 20.9 ms
16:55:43 - 21.3 ms
...
16:09:45 - 134.3 ms
16:10:21 - 142.1 ms
16:10:58 - 147.5 ms
...
17:18:51 - 177.3 ms
17:19:27 - 135.8 ms
17:20:03 - 179.6 ms

私はJavaソースパラメータPrintReferenceGCで見つけました。次に表示されたGCログ

[SoftReference, 0 refs, 0.0000050 secs]
[WeakReference, 6 refs, 0.0000030 secs]
[FinalReference, 113 refs, 0.0011180 secs]
[PhantomReference, 0 refs, 0.0000020 secs]
[JNI Weak Reference, 3.9010450 secs]

これは JNI Weak Reference の問題です。

4

2 に答える 2

3

すべての実行が Yourkit プロファイラーで行われたことが重要です。OpenJDK7 の fastdebug ビルドをインストールしました。このバージョンには、パラメーター -XX:+TraceReferenceGC があります。このパラメーターを使用して実行した後、gc ログに約 5000 個のファイナライザーが表示されました。この問題は、Yourkit のソケット プローブをオフにすることで解決されました。

于 2012-11-16T11:20:44.123 に答える
0

最初のステップとして、VisualVMまたは任意のツールを使用して、ヒープの使用パターンを分析できます。コードを最適化し、オブジェクト作成のホットスポットをチェックすることで解決策があるかもしれません。それは永続的な解決策になるはずです。

それが不可能な場合は、アプリケーションの動作に適した最適なヒープサイズとGCアルゴリズムを見つける必要があります。これは試行錯誤の方法になります。あなたは間違いなくドキュメントを調整する必要があります。ここで行っているチューニングは、後でアプリケーションの動作が変更されたり、ロードパターンが変更されたりすると、再び非効率になる可能性があります。

あなたにぴったりのコレクターを見つけてみてください。次のようないくつかのパラメータを微調整します

    -XX:+UseConcMarkSweepGC        
    -XX:SurvivorRatio=10 
    -XX:TargetSurvivorRatio=90 
    -XX:MaxTenuringThreshold=30

試行錯誤による。

于 2012-09-16T16:37:27.223 に答える