Java JVM: 仮想マシンのパフォーマンス監視、トラブルシューティング ツール (3)

1. 基本的なトラブルシューティング ツール

• JMC (Java Mission Control) およびJFR (Java Flight Recorder)
  • JMCはJava7からJDKに含まれており、直接「jmc」と入力することで起動できます。
  • 使用する前に、JMX 接続をサポートするように Java プロセスを構成し、起動時に構成を追加する必要があります。
    • -Dcom.sun.management.jmxremote.port=7091
    • -Dcom.sun.management.jmxremote.authenticate=false
    • -Dcom.sun.management.jmxremote.ssl=false
  • 商用機能のロックを解除し、フライト レコード設定を開きます (1 つ選択)
    • jcmd pid VM.unlock_commercial_features
    • -XX:+商用機能のロックを解除 -XX:+フライトレコーダー

• jps : Java 仮想マシン プロセス ステータス ツール 仮想マシン プロセス ステータス ツール
  • 構文: jps [オプション] [ホストID]
    • -q: PIDのみを出力します
    • -m: mainメソッドに渡されるパラメータを出力します。
    • -l: アプリケーション JAR ファイルの完全なパッケージ名または完全なパス名
    • -v: 仮想マシンの起動時に指定されたパラメータのリストを表示します。
  • 実行中の仮想マシン プロセスを一覧表示し、仮想マシン実行メイン クラス名とこれらのプロセスのローカル仮想マシンの一意の ID を表示できます。
  • RMI プロトコルを通じて RMI サービスが有効になっているリモート仮想マシンのプロセス ステータスをクエリすることもできます。パラメータ hostid は、RMI レジストリに登録されているホスト名です。

• jstat: 仮想マシン統計監視ツール
  • 仮想マシンのさまざまな実行ステータス情報を監視するためのコマンドライン ツール
  • クラスのロード、メモリ、ガベージ コレクション、さらには仮想マシン プロセスのコンパイルなどのランタイム データを表示できます。
  • 例
    • プロセス 2764 のガベージ コレクション ステータスを 250 ミリ秒ごとにクエリし、合計 20 クエリを実行します
    • jstat -gc 2764 250 20
    • クエリの結果は、2764 によって使用される新世代の Eden 領域 (E) がスペースの 6.2% を使用し、2 つの Survivor 領域 (S0、S1) が空で、古い世代 (O) と永続世代が 41.42% を使用していることを示しています。それぞれスペースの 47.20%、MinorGC (YGC) 16 回、所要時間 (YGCT) 0.105 秒、Full GC (FGC) 3 回、所要時間 (FGCT) 0.472 秒、すべての GC の合計所要時間 (GCT) 0.577秒

• jinfo: Java 構成情報ツール
  • 仮想マシンのさまざまなパラメータをリアルタイムで表示および調整します
• jmap: Java メモリ マッピング ツール
  • ヒープ ダンプ スナップショットを生成し、ファイナライズ実行キュー、Java ヒープ、およびメソッド領域の詳細をクエリすることもできます
• jhat: 仮想マシンのヒープダンプスナップショット分析ツール
  • jmap と併用して、jmap によって生成されたヒープ ダンプ情報を分析します。
  • 通常、アプリケーションがデプロイされているサーバーでは直接分析されません。
• jstack: Java スタック トレース ツール
  • 仮想マシンの現時点でのスレッド スナップショットを生成します。これは、スレッドが長時間停止している理由を特定するために使用されます。

2. 視覚的なトラブルシューティング ツール

• JHSDB: サービスエージェントベースのデバッグツール
• JConsole: Java モニタリングおよび管理コンソール
• VisualVM: 多重障害処理ツール
• Java Mission Control: 継続的なオンライン監視ツール

3. その他の障害関連

• 大容量メモリ ハードウェアでのプログラム展開戦略
  • 大容量メモリを搭載したハードウェア上でモノリシック アプリケーションを展開する主な方法
    • 単一の Java 仮想マシン インスタンスを通じて大量の Java ヒープ メモリを管理
      • ヒープ メモリの大きなチャンクを再利用することによって引き起こされる長い一時停止
      • 大容量メモリには 64 ビット Java 仮想マシンのサポートが必要です
      • ヒープ メモリ オーバーフローが発生した場合に大容量のスナップショット ファイルを生成できるようにアプリケーションが十分に安定していることを確認する必要があります。
      • 一般に、同じプログラムでも 64 ビット仮想マシンでは 32 ビット仮想マシンよりも多くのメモリを消費します。
    • 複数の Java 仮想マシンを同時に使用して論理クラスターを確立し、ハードウェア リソースを利用します。
      • ノードはグローバル リソースをめぐって競合します。最も一般的なのはディスク競合です。
      • 接続プールなどの特定のリソース プールを最も効率的に利用することが難しい
      • ノードは必然的に 32 ビット メモリによって制限され、各プロセスが使用できるメモリは 2GB のみです
      • ローカルキャッシュの多用
• クラスタ間同期によるメモリ オーバーフロー
• オフヒープメモリが原因で発生するオーバーフローエラー
  • Java オフヒープ メモリの制限
    • ダイレクト メモリ: -XX:MaxDirectMemorySize によってサイズ変更可能
    • スレッド スタック: -Xss でサイズ変更可能、メモリ不足により StackOverflowError がスローされる
    • ソケット バッファ領域: 各ソケット接続には、受信および送信の 2 つのバッファ領域があります。
    • JNI コード: コードが JNI を使用してネイティブ ライブラリを呼び出す場合、ネイティブ ライブラリによって使用されるメモリはヒープ内にありません。
    • 仮想マシンとガベージ コレクター: 作業時に一定量のメモリを消費する必要がある
• 外部コマンドによりシステムの速度が低下する
• サーバー仮想マシンのプロセスがクラッシュする
• 不適切なデータ構造により過剰なメモリ使用量が発生する
• Windows 仮想メモリが原因で長い一時停止が発生する
• セーフポイントによる長時間の停止