 | WebLogic Serverファンの皆様、こんにちはWebLogic Server勉強会通信です。 前回に引き続き2013年1月24日に開催された「第32回WebLogic Server勉強会@東京」の話題です。侍ズムの山本 裕介氏の「スローダウン、ハングを一発解決！ スレッドダンプはトラブルシューティングの味方」セッションをレポートします。本レポートではスレッドダンプの取得方法から解析のポイントを簡単にまとめています。 WebLogic Server勉強会では、これからもスレッドダンプ関連の話題を幅広く取り上げていく予定です。スレッドダンプで解析したアプリケーション分析、障害事例などの経験談をお待ちしています。 （日本オラクル Fusion Middleware事業統括本部 佐々木 政和） |
「スローダウン、ハングを一発解決！ スレッドダンプはトラブルシューティングの味方」
侍ズムの山本裕介氏の「スローダウン、ハングを一発解決！ スレッドダンプはトラブルシューティングの味方」セッション・レポートです。エンタープライズアプリケーションで開発者、運用者を良く悩ませる問題として、「スローダウン、ハング状態」があります。スローダウンはアプリケーションのレスポンスが極端に遅くなったり、処理時間が通常の数倍以上かかる状態です。ハングは反応が無く、まったく処理が進まない状態を示します。これらの状態を生み出す原因にはいろいろな可能性が考えられ、それにちなんで解析ツールも多岐にわたります。今回は運用環境でも開発環境でも一発でJVMを解析できるスレッドダンプを用いた解析の手順やコツを学びます。
スローダウン、ハングの原因
マシンスペック不足、割り当てCPU/メモリ不足、チューニング不足、不適切なアプリケーションサーバの設定、アプリケーションの不具合などインフラからアプリケーションの実装まで原因はいろいろで総合的な分析テクニックが必要になります。アプリケーション開発者の皆さまであれば、ロジックが非効率になっていないか？リソースの奪い合いが発生している箇所が無いか？I/O待ちで長時間ブロックされる可能性が無いか？など普段から気にされるポイントでしょう。不幸にして、期待通りの性能が出ないJavaのアプリケーションの場合は、まず「JVMの内部状態の推移」に注目して異常が無いか探ってみましょう。
スレッドダンプの取得方法
JVMプロセス内のスレッドの状態をダンプする「スレッドダンプ」はまさにJVMの見える化です。時系列に複数回採取されたダンプの遷移を分析することでそれぞれのスレッドがどのように変化しているか知ることができます。今回は、jps, jstackコマンドを使用してスレッドダンプを取得して見ましょう。まずjpsを実行するとJVMのプロセス（PIDとmainクラス名）がリストされます。WebLogic Serverインスタンスのmainクラスはweblogic.Serverですので、"Server"と出力されているのがこれから調べるプロセスになります。jstackでこのプロセス番号を指定して、複数回実行してスレッドダンプを取得します。なぜ、複数回取得するか？というと、それぞれのスレッドの動作状況を時系列で見ることによって実行中、ブロック中、デッドロックなど状態遷移を見ることができるからです。
スレッドダンプの分析
用意ができましたので、いよいよ分析作業の開始です。注目箇所は上の部分"スレッドヘッダー"です。スレッド名とその状態を知ることができます。スレッド名はweblogic.socket.Muxer[n]ソケットマクサー、weblogic.kernel.Default[n]実行スレッドなどで、状態は、runnable, waiting for monitor entry, in Object.wait()などの情報がダンプされています。
「侍」を実際に使ってみる
「侍」は山本氏が作成したJVMのスレッドダンプ解析ツール（GCログからGC前後のヒープメモリ状態のグラフ表示などの機能も提供）です。 操作はいたってシンプルで、侍を起動してスレッドダンプファイルをドロップするだけです。スレッド状態が色で区別されます。idle（グレー）, runnable（緑）, block待ち（赤）、block中（オレンジ）、deadlock（ドグロ）など。スレッドの名前またはボタンを選ぶことで選択したスレッドの詳細情報を見ることができます。前と同じ状態の場合は"<"で表示されるので簡単に状態の推移を把握できます。
侍でスレッドダンプを解析（デモ）
セッションの最後に侍を使用してスレッドダンプを解析し問題を解決した3つのデモが紹介されました。デモ1：データベースをアクセスしているアプリケーションを100スレッドで同時実行しているがCPU使用率が上がらない。なぜか？
スレッドダンプを取得して侍で解析すると、多くの実行スレッドがブロックしていました。データソースのコネクションプールの最大容量が不足していることが判明しました。最大容量を1から200に変更すると正常になりました。デモ2：Servletを利用したアプリケーションを実行しているがCPU使用率が上がらずレスポンスも返ってこない状態。なぜか？
スレッドダンプを侍で解析するとこれもブロック状態ばかり。アプリケーションを調べてみるとsyncronizedブロック内で長時間sleepしているためにblockが発生している模様。アプリケーションを修正後に正常に動作しました。デモ3：アプリケーションが止まっている。なぜか？
スレッドダンプを侍で解析すると、「ドグロ」が出て来た。これによりデッドロックが発生していることが判明。アプリケーションを分析すると二つのオブジェクトが、両方でリソースの奪い合いを行っていました。アプリケーションを修正し正常動作を確認しました。
求む、現場からの体験談、皆様の経験談を参加者で共有！
WebLogic Server勉強会は、参加者のスキルアップや参加者間のネットワークの拡大を目指して開催しています。次回以降のLightning Talksセッション発表ボランティアを募集しています。成功談・失敗談など何でも構いません。現場での体験談を参加者と共有ください。例えば、スレッドダンプで難題を解決！のような成功談（こんなテクニックを使っています）や失敗談（ここではまってしまいました）など、お待ちしています。
Lightning Talksセッションのスピーカー申込み：
スピーカー希望の方はTwitterで@OracleMiddle_jp をフォロー頂いた上で、「WebLogic Server勉強会でLT希望！」と＠OracleMiddle_jpでメンションください。連絡を頂戴しましたら、以降はDMもしくは、メールにて連絡させていただきます。
