大規模化・安定稼働・開発効率化…Webシステム開発・運用を乗り切るテクニック

第3回 トラブルシューティング①

この記事を読むのに必要な時間:およそ 2 分

代表的なトラブル

Webアプリのシステムにおけるトラブルの代表的なものには,次の5種類があります。

  • ① J2EEプロセスダウン
  • ② J2EEプロセスハングアップ
  • ③ J2EEプロセススローダウン
  • ④ タイムアウト
  • ⑤ OutOfMemory障害

今回は①のJ2EEプロセスダウンにおけるCosminexusでの調査の流れを詳述し,②~⑤については次回で解説します。

J2EEプロセスダウンの調査

J2EEプロセスダウンが発生した場合は,プロセスのどこのモジュールで発生したのかを特定することがポイントになります。まずCosminexusの「エラーリポートファイル」を解析します。エラーリポートファイルにはネイティブの情報が出力されるため,メモリダンプを解析する前に状況を把握して原因を特定できる場合があります。これで特定できなければ,OSのメモリダンプを調査します。メモリダンプとは,UNIXではcoreファイル,Windowsではワトソンログとユーザダンプです図4⁠。

図4 プロセスダウン時の調査の流れ

図4 プロセスダウン時の調査の流れ

エラーリポートファイルでの確認点

エラーリポートファイルでは,次の3点を確認します。

  • ① Java VM以外の異常終了かどうか
  • ② シグナルが発生したライブラリはどれか
  • ③ 発生したシグナルの種別

異常終了個所がJava VMか否かは,リポートの「Anunexpected exception...」の行の末尾で判別します。ここに「outside the VM」とあればJavaVM以外,⁠by HotSpot Virtual Machine」であればJava VMでの異常発生です。Java VMが異常終了した場合はVMのサポートに問い合わせるか,最新のパッチを探すなどしましょう。

どのライブラリでシグナルが発生したかは「Library=」の行で確認し,発生したシグナルの種別は「Unexpected Signal:」の行で判断します。シグナル種別から,ダウンしたライブラリ自体に問題があるか,呼び出し先のライブラリに問題があるかが判断できます図5⁠。

図5 エラーリポートファイルの解析

図5 エラーリポートファイルの解析

メモリダンプの解析

エラーリポートファイルの結果から,呼び出し先のライブラリを調査する必要があると判明した場合は,メモリダンプを解析します。なお,メモリダンプの取得は,UNIXとWindowsの場合で手順が異なります。UNIX系ではcoreダンプ,Windowsではワトソンログおよびユーザダンプを取得して解析を行います。

UNIXの場合

まずcoreファイルを開き,バックトレースを出力します。

異常終了した個所はシグナルハンドラがコールされた直後にあるので,上から順にバックトレースを見ていきます。

Windowsの場合

Windowsでは,まずワトソンログ(drwtsn32.log)を調べます。スレッドのステートダンプで「フォールト->」が表示されているスレッドを確認し,そのスタックバックトレースで出力される「*** ERROR」の個所がダウンした関数名です。

ワトソンログで詳細がわからない場合は,ユーザダンプを使用します。そのためには,Microsoftが配布しているwindbg.exeの入手が必要です。ユーザダンプを開くとビューが開くので,⁠~* kb」と入力して全スレッドのバックトレースを出力します。これを解析して異常終了個所を発見します。

異常終了個所は「*** ERROR」に表示されたライブラリで,異常個所はそれ以後に表示されるバックトレースの最初の行に記されています。

次回予告

本連載の次回ではトラブルシューティングの後編として,J2EEプロセスハングアップ,J2EEプロセススローダウン,タイムアウト,OutOfMemory障害のそれぞれについて,調査手順を解説します。