1

そこで私は、JVM が OOM の状況に向かう可能性がある時期を監視するための良い方法を突き止めようと試みてきました。私たちのアプリで機能すると思われる最善の方法は、CMS を介してバックツーバックの同時モード障害を追跡することです。これは、Tenured プールが実際にクリーンアップできるよりも早くいっぱいになっているか、ほとんど再生されていないことを示しています。

GC を追跡するための JMX Bean には、前後のメモリ使用量などの非常に一般的な情報があります。この情報は、せいぜい比較的一貫性がありません。この死にかけている JVM の潜在的な警告サインを監視するためのより良い方法はありますか?

4

2 に答える 2

2

Sun JVM を使用していると仮定すると、2 つのオプションがあることがわかります。

  1. メモリ管理 mxbeans (API リファレンスはここから始まります) を既に使用しているようですが、アクセスできるホットスポット固有の内部のものがあることに注意してください。使用方法の例については、このブログを参照してください。
  2. jstat: cmd reference is here、-gccauseオプションが必要になります。これを起動して出力を解析するスクリプトを作成するか、理論的には、ホスト jvm (または別のホスト) からプロセスを生成して、jstat から出力ストリームを読み取り、gc の原因を検出することができます。ただし、原因レポートが 100% 包括的であるとは思いません。この情報を Java コードからプログラムで取得する方法がわかりません。
于 2011-03-29T20:52:28.813 に答える
0

標準の JRE 1.6 GC では、アプリケーションの性質と指定された最大ヒープ サイズに応じて、ガベージ コレクターの実行頻度が徐々に低下し、時間の経過とともにヒープ使用率が上昇する傾向にあります。とはいえ、より多くの情報がなければ、何が起こっているのかを言うのは難しい.

さらに調査するためのいくつかの方法：

jmap を使用して実行中にアプリケーションのヒープ ダンプを取得し、jhat を使用してヒープを検査して、任意の時点でどのオブジェクトがヒープ内にあるかを確認できます。

-XX:+HeapDumpOnOutOfMemoryError を使用してアプリケーションを実行することもできます。これにより、JVM で最初にメモリ不足の例外が発生したときにヒープ ダンプが自動的に作成されます。

アプリケーションに固有のモニタリング Bean を作成し、リモート JMX クライアントでヒットできるアクセサ メソッドを作成できます。たとえば、プログラムでメモリを使用する可能性が高いキューやその他のコレクションのサイズを返すメソッドです。

HTH

于 2011-03-29T18:45:53.297 に答える