最近、最大ヒープ サイズが小さすぎるために、サービスの 1 つがガベージ コレクションに長時間かかっていることがわかりました。このサービスは私が始める前から存在していたので、ヒープ サイズが小さいことに気づきませんでした。特定のポイントを超えて上昇した場合に警告するようにアラームを設定したいのですが、実際に必要な以上のリソースを与えたくありません。ガベージ コレクションとヒープの使用率について警戒すべき妥当なレベルはどれくらいだと思いますか?
平均ヒープ使用率のアラームは約 85% で、100 ミリ秒の gc/5 分になると考えていました。
これが要件とハードウェアに基づいていることは理解していますが、決定を下すためのベンチマークまたは標準を実際に探しています。
アレックス・ロックウッドの答えはこう言っています：
推奨されるヒープ メモリ使用量と GC 時間の「最大レベル」は、可能な限り少なくします。
それは誤解を招くものです。私は実際には逆をお勧めします。アプリケーションが GC をより頻繁に実行し、有用な作業に費やす時間が (平均して) 少なくなるため、ヒープ サイズを圧縮しようとするのは悪い考えです。
問題は基本的にこれです。JVM がオブジェクトを割り当てるためのスペースを使い果たすと、従来の (非並行) GC が実行されます。次に、ガベージ以外のオブジェクトをトラバースし、それらを別の「スペース」にコピーします。GC サイクルを実行するためのプロセッサ時間は、非ガベージの量に最も強く依存します...しかし、それが達成する有用な作業 (解放するスペースの量) は に比例しheapsize - nongarbageます。したがって、ヒープサイズを絞ると、GC が実行する有用な作業の量が減少します...同じプロセッサ時間の消費に対して。
元の質問には次のように書かれています。
平均ヒープ使用率のアラームは約 85% で、100 ミリ秒の gc/5 分になると考えていました。
GC CPU 使用率の絶対レベルでモニター/アラームを設定することはおそらく役に立ちません。GC 時間は、サーバーのアクティビティと GC の効率によって異なります。サーバーがビジー状態になるたびに GC アラームが鳴るようにしたくありません。
85% の平均ヒープ使用率は警告を発する妥当なレベルですが、固定レベルでアラームを設定すると、あまりにも多くの誤報が発生する可能性があります。
これに代わる方法は、JVM オプションを使用して「GC で費やされた時間の割合」のしきい値を設定し、それを「OutOfMemoryException で JVM を強制終了する」オプションと組み合わせて、サーバーの起動スクリプトに自動再起動ループを配置することです。次に、再起動を監視します。
これは、作成したコンテキストとプログラムに完全に依存します。
推奨されるヒープ メモリ使用量と GC 時間の「最大レベル」は、可能な限り少なくします。