問題の本質にたどりつくため、サーブレットの応答時間と、システムスレッドプールに関連するメトリックとオープンしている接続の件数の相関関係に注目することにしました。そこで、新しいビューを「ユーザービュー」の下に作成し、「メトリック・ブラウザ」を使えるようにしました。まずは、調査対象のサーバインスタンスを選択し、「実行」ボタンをクリックします。すると３個のリンクと、その左側にコンテキストによって変化する選択ボタンが現れるので、タイプ、インスタンス、特定のメトリックを選択し、そのメトリックを右側のスペースにドラッグアンドドロップすると、新しいグラフができあがります。その他のメトリックについても同様に実施します。ビルトインの尺度法がない場合でも、簡単に構成することができます。間違えた場合や、値が変化して作成したマッピングでは意味をなさないような場合でもドラッグアンドドロップで元に戻すことができますし、問題のメトリックを単にドラッグして新しいグラフや別のグラフを作成することもできます。個々のグラフをそれぞれ個別に計測期間を長くしたり短くしたりすることもできます。最後に左側のスタートボタンを押すと、計測を開始します。
このビューから、高負荷であっても正常に稼働していることをすぐに確認できるようになりました。負荷発生ツールからの平均接続件数および応答時間は一定でした。
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としています。
hogging threadが定期的な作業フローを終了できないと想定し始めたので、かなりの数の新しいスレッドが追加されていることが確認できます。最後に、我々はすべてのhog threadが引き戻されていることがわかります。保留中のリクエストはなくなり、即時実行可能な60個の追加された空きスレッドが残っていることがわかります。
問題のサーブレットを開発チームとレビューしたところ、レガシーシステムに接続している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 件のコメント:
コメントを投稿