[WLS] Using the Dashboard to Isolate Poor Performance to the Back End

WebLogic診断ダッシュボード(WebLogic Diagnostics Dashboard)はWebLogic Serverに組み込まれていますが、11gR1PS2 (10.3.3)で刷新され、高速・軽量で、以前のものよりもインタラクティブになっており、グラフィカルなビューで現在何が起きているのかを手早く知ることができます。コンソールにログインすると、右下の「Charts and Graphs」に「Monitoring Dashboard」へのリンクがありますので、クリックしてみてください。

問題の本質にたどりつくため、サーブレットの応答時間と、システムスレッドプールに関連するメトリックとオープンしている接続の件数の相関関係に注目することにしました。そこで、新しいビューを「ユーザービュー」の下に作成し、「メトリック・ブラウザ」を使えるようにしました。まずは、調査対象のサーバインスタンスを選択し、「実行」ボタンをクリックします。すると3個のリンクと、その左側にコンテキストによって変化する選択ボタンが現れるので、タイプ、インスタンス、特定のメトリックを選択し、そのメトリックを右側のスペースにドラッグアンドドロップすると、新しいグラフができあがります。その他のメトリックについても同様に実施します。ビルトインの尺度法がない場合でも、簡単に構成することができます。間違えた場合や、値が変化して作成したマッピングでは意味をなさないような場合でもドラッグアンドドロップで元に戻すことができますし、問題のメトリックを単にドラッグして新しいグラフや別のグラフを作成することもできます。個々のグラフをそれぞれ個別に計測期間を長くしたり短くしたりすることもできます。最後に左側のスタートボタンを押すと、計測を開始します。

このビューから、高負荷であっても正常に稼働していることをすぐに確認できるようになりました。負荷発生ツールからの平均接続件数および応答時間は一定でした。
 WebLogic Serverスレッドプールランタイムの統計情報を使うと、サーバでの処理に関して別の見方ができます。
  • サーバは負荷に対応するためにどれぐらいの個数のスレッドを作成しているか
  • どれぐらいの負荷度合か
  • アイドルスレッドおよびその他のスレッドをセルフチューニングでどれぐらい使っているか
セルフチューニングスレッドプールはサーバに組み込まれているものですが、これが待ち状態の処理件数と各スレッドが処理完了速度を定常的に監視し、チェックしています。この情報を使ってスレッドを追加すべきか待ち行列に入れるかを決めます。この説明は以下のエントリに詳しいです。

Threads Constraints in Work Managers
https://blogs.oracle.com/WebLogicServer/entry/threads_constraints_in_work_ma

"Hogging Threads"というものがあります。”Hogger”とは処理に長時間要しているスレッドのことですが、処理終了に4秒以上かかっているHogging Threadsを調査し始めました。ほとんどのアプリケーションでは4秒が生存期間で、例外は出なかったのです。hogging threadsの個数をサンプリングすれば、バックエンドシステムで起こっていることが簡単にわかります。

[訳注] Hogging Threadはあえて日本語にせず、hogging threadとしています。

このグラフのはじめでは、処理の到着を待っているアイドルスレッドが多数あります。3:47から3:49にかけてhogging threadsの個数にスパイクが発生しています。これは何らかの理由で処理に時間がかかっているようです。サーバが新しいスレッドを作成せず、リクエストを待ち行列に入れているので、処理待ちのリクエストの件数が増えていることがわかります。長期にわたってスレッドが必要でないのであれば、たくさんのスレッドをアドホックに作成したくないので、システムは本当に必要になるまでスレッドの作成を抑制しています。
hogging threadが定期的な作業フローを終了できないと想定し始めたので、かなりの数の新しいスレッドが追加されていることが確認できます。最後に、我々はすべてのhog threadが引き戻されていることがわかります。保留中のリクエストはなくなり、即時実行可能な60個の追加された空きスレッドが残っていることがわかります。

同じ時間帯で計測した実行時間のグラフでも同様です。システムの処理が遅くなるにつれてスループットが徐々に小さくなっています。負荷が安定しているにもかかわらず、接続ユーザ数が増加しているのは、処理完了を待っている接続ユーザが増えているためである、ということがわかります。この応答していない特定のサーブレットとの相関も明らかです。この場合、平均レスポンスタイムは通常時のほぼ2倍になります。前のグラフと合わせて見ると、突然スループットが急増して、バックログがなくなったことがわかります。
問題のサーブレットを開発チームとレビューしたところ、レガシーシステムに接続しているUNIXプロセスのプールに直接渡されているといることが問題で、対応策があることがわかりました。EJBやJDBC、JMSなどをアプリケーション内で使用していたため、このサブシステムに関わるメトリックをサンプリングし、問題を特定しようとしました。
このツールの問題点は、作成したビューをインポート/エクスポートする術が現時点では存在しないということです。回避策として、トリッキーではありますが、保存済みのコンソール設定を収集しました。
<Domain_Home>/servers/<管理サーバ名>/data/console/ConsolePreferences.xml に、 カスタムダッシュボードビューの説明も含めて、コンソールに保存したすべての設定が含まれています(このエントリを記載している時点での内容です)。重要な部分は、以下で始まる部分です。
<portlet-preference definitionLabel="dashboard" user="weblogic">
保証はありませんが、管理サーバ停止中に単純にカット&ペーストしてこの部分をファイルに書き出したところ、グラフがよみがえりました。

今後、WebLogic Diagnosticsを使って、効率的にプロパティのアーカイブを維持し、事象発生後にダッシュボードにログインして同じ情報を見ることができる方法をご案内する予定です。


原文はこちら。
https://blogs.oracle.com/WLSPERFORMANCE/entry/tricks_for_working_with_the

0 件のコメント:

コメントを投稿