Java サーバー側アプリケーションがあります。スレッド数は1000までです。アプリは通信にNIOやJINIなどを多用しています。
1 分あたり 400 メガバイトの割り当て/割り当て解除は、Java アプリケーションにとってまったく問題ない (許容できる) と考えますか?
質問する理由 - 使用可能なメモリの量は時間の経過とともに少なくなります: メモリ リーク (1 日あたり数メガ) があり、使用されるメモリの量は実行する作業の量によって異なります (アプリはいくつかのものをキャッシュします)。そのため、空きメモリが 100 MB 以下の状況が発生する可能性があります。GC の活動が非常に要求されるようになると、当然ながら GC はおかしくなります。(再起動の推奨実行時間は、本番環境で 1 か月です)
400 MB/秒のガベージは非常に悪いです。
アプリケーションでは、400 MB/分のガベージが問題ない場合があります。
Eden のサイズ-XX:NewSize=を 1g、2g、または 4g に増やして、パフォーマンスが向上するかどうかを確認します。
これが CPU の数よりも多い場合は、特にアクティブなスレッドの数を推定しようとします。
スレッド数は最大 1000 です。
それはおそらく多すぎます、IMO。各スレッドのスタックは、プラットフォームと-Xss.
1 分あたり 400 メガバイトの割り当て/割り当て解除は、Java アプリケーションにとってまったく問題ない (許容できる) と考えますか?
それは問題ではないはずです。実際、パフォーマンス グラフを見ると、GC は使用されている CPU 時間のごく一部のように見えます...そしてそれは利用可能な時間のごく一部です。
質問する理由 - 使用可能なメモリの量は時間の経過とともに少なくなります: いくつかのメモリ リーク (1 日あたり数メガ) があります。
これらのリークを追跡して修正することを検討する必要があります。
...また、使用されるメモリの量は、実行する作業の量によって異なります (アプリはいくつかのものをキャッシュします)。
その答えは、ヒープサイズを増やすことかもしれません。そして (驚くべきことに) ヒープ サイズを大きくすると、ガベージ コレクションに費やす時間の割合を減らすことができます。(同時コレクターと非常に大きなヒープに問題がある可能性がありますが...)
そのため、空きメモリが 100 MB 以下の状況が発生する可能性があります。GC の活動が非常に要求されるようになると、GC はもちろんおかしくなります。
はい。これは、高い割り当て率ではなく、ストレージ リークの結果である可能性が最も高いです。JVM がヒープの不足に近づくにつれて、GC が全体の実行時間に占める割合が増加します。それは避けられません。(GC はほとんどの時間をガベージではないオブジェクトの処理に費やします。再利用可能なスペースの割合が減少するにつれて、そのスペースを再利用するためのコストが上昇します。)
-XX:+UseGCOverheadLimitこれには、 JVM スイッチの形で回避策があります。これは、「OutOfMemory エラーがスローされる前に GC で費やされる VM の時間の割合を制限するポリシー」を使用します。. 基本的に、サーバーがパフォーマンスを低下させる死のスパイラルに陥る前に、必然的なOOMEがスローされました...
(再起動の推奨実行時間は、本番環境で 1 か月です)
...またはメモリリークを修正!!!