2

Netty に基づくサーバー アプリケーションがあります。メッセージを (json から) デコードし、クライアントに送り返します (単純なエコー)。1 つのクライアント (15k/秒以上) から大量のメッセージを送信すると、ガベージ コレクターが起動せず、メモリ使用量が増加します。

gc の一時停止を減らし、メモリ使用量を減らすように jvm を構成するにはどうすればよいですか?

4

2 に答える 2

4

あなたの説明はメモリリークのように聞こえます。ガベージ コレクターは最終的に開始されますか、それとも ? で終了しますOutOfMemoryErrorか?

そうしないと、オブジェクトが Tenured 世代に入るのに十分な長さで存続している状況に陥っているように思えます (ここでは Sun JVM を想定しています)。その解決策は、在職世代に比べて若い世代の規模を拡大することです。

Sun JVM世代別コレクターを説明するリンクは次のとおりです(これは1.5 JVM用ですが、オプションは1.6でも変更されていないと思います): http://www.oracle.com/technetwork/java/gc-tuning-5 -138395.html

試してみたいオプションはNewRatio、若い世代と終身世代SurvivorRatioの比率である と、Eden と 2 つの生存者スペースの比率である です。私は次のことを試すかもしれません：

  • -XX:NewRatio=1若い世代にオブジェクト ヒープの半分を与える
  • -XX:SurvivorRatio=2各生存者のスペースをエデンの半分にする

これらの 2 つの設定により、新しいオブジェクトの「Eden」スペースがヒープの 1/4 を占めるようになります。これはかなり大きいので、ほとんどのオブジェクトが Eden で一生を過ごすことを願っています。サバイバー レーションは、ヒープのさらに 1/4 をサバイバー スペースに与え (それぞれに 1/8)、中程度の寿命を持つオブジェクトを保持します。

もちろん、やみくもにオプションを設定しないでください。代わりに、jconsole(JDK ディストリビューションの一部) を使用して、ヒープで実際に何が起こっているかを確認してください。デフォルトの生存率 (1:6) は、私が提案したものよりも優れていることに気付くかもしれません。

于 2011-04-07T14:02:01.487 に答える
0

gc の一時停止とメモリ使用量を減らすように jvm を構成するには、適切な GC コレクターを選択する必要があります。CMS は低休止コレクターです。-XX:+UseConcMarkSweepGC を設定して有効にすることができます。また、次のような他のパラメーターを微調整できます。

-XX:+UseCMSInitiatingOccupancyOnly
-XX:CMSInitiatingOccupancyFraction=nn

GC の一時停止を制御します。

于 2012-10-17T16:10:38.897 に答える