以下のトラブルシューティングのガイドラインを利用すると、Java に関する多くの問題の根本原因を特定できます。
ステップ1. CPU飽和の有無
JVMのCPUが飽和状態ですか？
確認方法
- ティアフローマップを表示する。
- [Nodes] タブをクリックし、[Hardware] データを表示する。
- CPU %（現在）で並べ替える。
[CPU %] が 90 以上の場合、この質問の答えは「はい」となります。それ以外の場合は「いいえ」となります。
「はい」の場合 - Step 2 に進みます。
「いいえ」の場合 – 問題は所属の組織が開発したカスタムの実装に関連している可能性がある。影響を受けたティアまたはノードのスナップショットを取得し、問題解決のために内部のデベロッパと協力する。
ステップ2：非常に頻繁なガベージコレクションアクティビティの有無
非常に頻繁なガベージコレクションアクティビティがありますか？
確認方法
- ティアフローマップを表示する。
- Nodesタブをクリックし、Memoryタブをクリックする。
- [GC Time Spent] で並べ替え、1 分間あたり何ミリ秒が GC に費やされているかを確認する。60,000 が 100% を意味する。
- [GC Time Spent] が 500 ミリ秒以上の場合、ステップ 5 の質問の答えは「はい」となります。それ以外の場合は「いいえ」となります。
結果
「はい」の場合 - Step 3 に進みます。
「いいえ」の場合 - Step 4 に進みます。
ステップ3：メモリリークの有無
メモリリークが発生していますか？
確認方法
- 前の手順（ガベージコレクションのアクティビティの確認）で表示されたノードリストから、非常に頻繁にガベージコレクションアクティビティが発生しているノードをダブルクリック。
- [Memory] タブをクリックし、スクロールダウンしてパネル下部のメモリプールのグラフを表示する。
- [Old Gen memory pools] チャートをダブルクリック。
メモリが解放されていない場合（使用が上昇傾向にある）、この質問の答えは「はい」となります。それ以外の場合は「いいえ」となります。
結果
「はい」の場合 – さまざまな Splunk AppDynamics 機能を使用し、リークを追跡する。メモリリークの診断に便利なツールの1つは、オブジェクトインスタンス追跡。作成しているオブジェクトを追跡でき、必要に応じてそれらが解放されていない理由を判断することができる。オブジェクトインスタンス追跡の構成手順と、メモリリークの発見と修正を行う他のツールへのリンクについては、「Need more help?」を参照。
「いいえ」の場合 – JVMのサイズを増やす。非常に頻繁なガベージコレクションアクティビティがあっても、メモリリークがない場合、コードが実行される十分なヒープサイズを構成していない可能性がある。そのため利用可能なメモリを増やすことで問題が解決される可能性が高い。
回答が「はい」でも「いいえ」でも、問題が特定されます。
ステップ4. リソースリークの有無
リソースリークが発生していますか？
確認方法
- 左のナビゲーションペインで、（たとえば）Metric Browser > Application Infrastructure Performance > TierName > Individual Nodes > NodeName > JMX > JDBC Connection Pools > PoolName に移動する。
- Active Connections および Maximum Connections メトリックをグラフに追加する。
- 必要に応じて、アプリケーションが使用している複数のプールについて繰り返す。
接続が解放されていない場合（使用が上昇傾向にある）、ステップ 7 の質問の答えは「はい」となります。それ以外の場合は「いいえ」となります。
結果
「はい」の場合 - リソースが作成されているが、必要に応じて解放されていないコード内の場所を特定するために、問題のノードで標準コマンドを使用してスレッドダンプをいくつか取得する。また、Splunk AppDynamics 内で診断アクションを作成することでも、スレッドダンプを作成できる。「診断アクション」の「Thread Dump Actions」を参照。
「いいえ」の場合 - JVM を再起動する。上記の診断手順で問題が解決しない場合、一度限りの稀な状況の可能性がある。その場合、JVM の再起動で解決する場合がある。