応答遅延が発生した場合の，トラブルシュートの流れを次に示します。

図6-7　応答遅延発生時の対処フロー

フローの詳細で示した処理の詳細は(2)で説明します。

応答遅延のフローの内容に沿って，それぞれの作業について説明します。

1. CPUの利用率を調査する
   該当するプロセスのCPU利用率を調査します。
   タスクマネージャでCPU利用率を表示した例を次に示します。
   

   図6-8　CPU利用率

   

   ポイント

   1coreが100％に近い場合

   無限ループや再帰呼び出しに陥っているケースが考えられます。CPUネックが原因と考えられます。手順2.へ進んで調査を進めてください。

   1coreが0％に近い場合

   バックプロセスから応答が返ってきていないことが原因による，バックプロセス無応答やデッドロックが考えられます。手順2.へ進んで調査を進めてください。

2. PRFトレースを取得する
   mngsvrutilコマンドを実行すると，PRFトレースを出力できます。
   

   実行例

   mngsvrutil -m 123.45.67.89 -u admin2 collect allPrfTraces

3. PRFトレースを開く
   PRFトレースを開きます。
   

   出力先

   C:\Program Files\Hitachi\Cosminexus\manager\log\prf

   ファイル名

   トレース情報の収集対象別に次に示すファイル名で出力されます。

   なお，<日時>には，PRFトレースを収集した日時が表示されます。

   パフォーマンストレーサの種類	ファイル名
   運用管理ドメイン内のホスト上で動作しているすべてのパフォーマンストレーサ	<運用管理ドメイン名>−<日時>.zip
   特定のホスト上で動作しているすべてのパフォーマンストレーサ	<ホスト名>−<日時>.zip
   特定のパフォーマンストレーサ	<論理サーバ名>−<日時>.zip

4. PRFトレースを調査する
   PRFトレースのTime列を確認して，長時間を要している処理を探します。
   PRFトレースは，プロセスにわたりイベントを出力するトレース情報で性能解析・障害解析に有効な資料です。
   

   図6-9　PRFトレースの出力例

   

   例の場合，SQL発行後11分の空白があります。さらにSQLの実行は終了していません。したがって，SQL実行中にDBに何らかの問題が発生したものと考えられます。
   なお，PRFトレースは表計算ソフトで表示すると確認しやすくなります。
   
5. スレッドダンプを出力する
   mngsvrutilコマンドを実行すると，スレッドダンプを出力できます。
   

   実行例

   mngsvrutil -m 123.45.67.89 -u admin2 dump server

6. スレッドダンプを調査する
   

   無限ループの場合

   無限ループの場合のスレッドダンプの出力例，および調査のポイントについて説明します。

   図6-10　スレッドダンプ（無限ループ）の出力例

   
   

   スレッドダンプを複数回出力して，時系列で観察し，それぞれのスレッドダンプでtidの同じスレッドのスタックトレースを比較調査します。

   ポイント1

   スレッド属性がrunnableの場合，このスレッドは実行可能状態にあります。このスレッドがCPU利用率の増加に関与しています（waiting for monitor entryの場合は実行可能状態ではないので，CPU利用率を増加させません）。

   ポイント2

   複数のスレッドダンプファイルで，同一のtidのスレッド属性がすべてrunnableです。

   長時間にわたって実行中の可能性があります。

   ポイント3

   同一メソッド内の特定の行が，繰り返し実行されているような場合，無限ループの疑いがあります。

   ポイント

   ここまでの調査で，無限ループの疑いがある場合は，開発元へ調査を依頼してください。

   無限ループの疑いがない場合は手順7.へ進んでください。

   デッドロックの場合

   デッドロックの場合のスレッドダンプの出力例，および調査のポイントについて説明します。

   図6-11　スレッドダンプ（デッドロック）の出力例

   
   

   デッドロックが発生している場合のスレッドダンプの例を示します。

   出力例の「nid:...」に続いてスレッド属性が出力されます。

   「waiting for monitor entry」となっているスレッドを探します。

   「-waiting to lock...」，および「-locked...」の内容を確認し，お互いがロックしている領域のロック取得待ちが発生していればデッドロック状態です。

   ポイント1

   スレッド属性がrunnableの場合，このスレッドは実行可能状態にありますので，このスレッドはデッドロックとは無関係です。

   ポイント2

   スレッド属性がwaiting for monitor entryである場合，このスレッドはロックの取得待ちであることを示しています。

   デッドロックを起こしているスレッドである可能性があります。

   ポイント3

   スレッドがロックを取得していて，かつ，ポイント2でスレッドのロック待ちの場合，デッドロックを起こしているスレッドである可能性がさらに高いです。

   ポイント2，ポイント3に当てはまるスレッドに対して，ロックしているオブジェクトのアドレスを突き合わせながらデッドロックを検出します。

   例の場合，Thread-3は，<02A328C8>のロックを取得して，かつ<02A328C0>の取得待ちを示します。

   一方，Thread-1は，<02A328C0>のロックを取得していて，かつ<02A328C8>の取得待ちとなっていて，Thread-3とThread-1がデッドロックしていることがわかります。

   ポイント

   ここまでの調査で，デッドロックの疑いがある場合は，開発元へ調査を依頼してください。

   デッドロックの疑いがない場合は手順7.へ進んでください。

7. 業務アプリケーションを改修する。冗長な処理を取り除く
   PRFトレース，およびスレッドダンプの調査の結果を基に，業務アプリケーションで遅延している疑いがある場合は調査して対策します。
   

   ポイント

   問題が解決した場合は，これでトラブルシュートは完了です。

   問題が解決しない場合で，CPU使用率が高い場合は，手順8.へ進んでください。

   問題が解決しない場合で，CPU使用率が低い場合は，ご購入契約に基づくお問い合わせ窓口に調査を依頼してください。

8. 同時実行スレッド数のパラメタを小さくして，同時実行処理数を抑える
   実行待ちリクエストが溜まることがありますが，多少処理を待たせた方がよいです。
   
9. マシンのCPUを増設する
   CPUの増設では，ミドルウェアのライセンス費用の追加に注意してください。
   
10. マシンを追加し，トランザクションを負荷分散させる
    マシンを追加する場合は，ハードウェア／ソフトウェアのライセンス費用の追加に注意してください。
    

    ポイント

    問題が解決した場合は，これでトラブルシュートは完了です。

    問題が解決しない場合は，ご購入契約に基づくお問い合わせ窓口に調査を依頼してください。