WebLogic Server のアーキテクチャ(スレッド管理)

<Insert Picture Here>

WebLogic Server のアーキテクチャ(スレッド管理)

日本オラクル株式会社カスタマーサービス統括本部テクニカルアナリスト大類和久2009年 4月14日

Copyright© 2009, Oracle. All rights reserved. 2

以下の事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。また、情報提供を唯一の目的とするものであり、いかなる契約にも組み込むことはできません。以下の事項は、マテリアルやコード、機能を提供することをコミットメント（確約）するものではないため、購買決定を行う際の判断材料になさらないで下さい。オラクル製品に関して記載されている機能の開発、リリースおよび時期については、弊社の裁量により決定されます。

Oracle、PeopleSoft、JD Edwards、及びSiebelは、米国オラクル・コーポレーション及びその子会社、関連会社の登録商標です。その他の名称はそれぞれの会社の商標の可能性があります。


Agenda

• アプリケーションサーバにおけるスレッド管理の必要性

• WebLogic Server 10.3 のスレッド管理のアーキテクチャ

• コンフィグレーション

• TIPS


アプリケーションサーバにおけるスレッド管理の必要性

• 多数のクライアントからのリクエストを処理する必要がある

• 多重、同時でリクエストを処理する必要がある

• マルチスレッドで複数のリクエストを処理するのが最適

クライアント

キュー

アプリケーションサーバ

スレッド

・

・

・


アプリケーションサーバにおけるスレッド管理の必要性

• WebLgoic Server 8.1 以前のアーキテクチャ

WebApp A

WebApp B

EJB A

クライアント

ソケットリーダー

アプリケーション

実行キュー

スレッドプール


WebLogic Server 10.3 のスレッド管理のアーキテクチャ- 新たなアーキテクチャの必要性

• WebLgoic Server 8.1 以前のアーキテクチャの課題• スレッド数の調整が難しい

• アプリケーションで必要なスレッド数を正確に決定するのは困難

• 多くし過ぎるとスレッド作成で起動が遅くなり、少ないと高負荷時の同時実行性が下がるというジレンマ

• スレッドは高価なリソースのため、少ないスレッドを効率的に使用したい

• アプリケーション毎のプライオリティ付けが困難• スレッドプール毎にスレッドのプライオリティを設定可能だが、OS レベルの設定

のため大袈裟

• 新たなアーキテクチャが必要


WebLogic Server 10.3 のスレッド管理のアーキテクチャ- 新たなアーキテクチャ

• 単一の自動チューニングスレッドプールの導入• 1 つのスレッドプールを複数のアプリケーションが利用する

• スループットの測定に基づいて、自動でスレッド数が調整される

• 初期のスレッド数は少ないため、起動時間に影響を及ぼさない

• ワークマネージャの導入• アプリケーション毎、ユーザ毎等の細かいプライオリティ付けが可能

• このアーキテクチャは WebLogic Server 9.0 から導入


WebLogic Server 10.3 のスレッド管理のアーキテクチャ- 概要図

ワークマネージャサブシステム


WebApp A

WebApp B

EJB A

コンソール

クライアント

ソケットリーダー

Default ワークマネージャ

ワークマネージャ A

ワークマネージャ B

ワークマネージャ C


WebLogic Server 10.3 のスレッド管理のアーキテクチャ- スレッドの増減


スレッドが不要ワークマネージャ A

ワークマネージャ B

Active Thread

Standby Thread

２秒間隔でスループットの監視

スレッドが必要


WebLogic Server 10.3 のスレッド管理のアーキテクチャ- リクエストのプライオリティ付け


ワークマネージャ Bスレッドプール

A

B

A B

リクエストのプライオリティで順序を変更


コンフィグレーション- 種類

• 制約• 最小スレッド数制約

• 最大スレッド数制約

• 容量制約

• 要求クラス• フェアシェア要求クラス

• 応答時間要求クラス

• コンテキスト要求クラス


コンフィグレーション- 最小スレッド数制約

• 最小スレッド数制約

• 最小の並列実行数を制御

• プールにスレッドが存在するかに関わらず、スレッドを作成してでも実行

• 起動時に作成されるスレッド数とは関係しない

• 主な目的はデッドロックの防止


スレッドプールMinThreadConstraint = 3


コンフィグレーション- 最大スレッド数制約

• 最大スレッド数制約

• 最大の並列実行数を制御

• 複数のワークマネージャより共有することが可能

• 合計のスレッド総数が制約の対象となる


スレッドプールMaxThreadConstraint = 3

実行中


コンフィグレーション- 容量制約

• 容量制約

• キューに溜まるリクエストと実行中のリクエストの総数の最大数

• オーバーロードの防止


スレッドプールCapacity = 6

実行中


コンフィグレーション- 要求クラス

• 要求クラスとは？• リクエストの重みを決定するもの

• 空きスレッドが無い状態での、スレッドの割り当て時に作用


コンフィグレーション- 要求クラス

• フェアシェア要求クラス• 相対的なプライオリティを設定する

• 例) 100

• 応答時間要求クラス• 目標とする応答時間を設定する

• 例) 2000 msec

• 待ちキューに滞留する時間をコントロール

• あくまで目標値の設定

• コンテキスト要求クラス• ユーザ毎に要求クラスを決定する

• 要求クラスのネストを作成


コンフィグレーション- 要求クラス例

• 例１• ワークマネージャ A (フェアシェア 100)

• ワークマネージャ B (フェアシェア 200)

• 高負荷でリクエストを投入

• 1:2 の割合でスレッドが割り当てられる

• 例２• ワークマネージャ C (応答時間 2000ms)

• ワークマネージャ D (応答時間 1000ms)

• 高負荷でリクエストを投入し、アプリケーション実行時間が一定と仮定する

• 1:2 の割合でスレッドが割り当てられる


コンフィグレーション- 要求クラス例

• 例３• フェアシェア要求クラスをネストしたコンテキスト要求クラス

• ユーザ： system は 100 を設定したフェアシェア要求クラスを使用

• 他のユーザ : everyone は 50 を設定したフェアシェア要求クラスを使用

• ユーザ : system のリクエストは他のユーザより高い優先度でスレッドが割り当てられる


コンフィグレーション- ワークマネージャの定義

• グローバルワークマネージャ• config.xml で定義

• アプリケーションスコープワークマネージャ• weblogic-application.xml (EAR)

• weblogic-ejb-jar.xml (EJB)

• weblogic.xml (WAR)

で定義

<work-manager>

<name>WM01</name>

<fair-share-request-class>

<name>share20</name>

<fair-share>20</fair-share>

</fair-share-request-class>

</work-manager>


コンフィグレーション- ワークマネージャの使用法

• Web アプリケーション• Servlet 単位

• web.xml<init-param>

<param-name>wl-dispatch-policy</param-name>

<param-value>WM01</param-value>

</init-param>

• Web アプリケーション単位

• weblogic.xml<wl-dispatch-policy>WM01</wl-dispatch-policy>

• EJB• weblogic-ejb-jar.xml

<dispatch-policy>WM01</dispatch-policy>


TIPS

• 起動直後のパフォーマンスの立ち上がりが悪い

• Why?

• 起動直後はスレッドプール内のスレッドは少ない

• スレッドは、スループットの測定で必要と判断された際に初めて増加する

• 対応策

• 基本的には、ワークマネージャの設定による自動チューニングを推奨

• 起動直後にピークアクセスが発生することが分かっている場合に限り、内部オプションでスレッドプール内のスレッド数を調整することも有効

• config.xml<server>

<name>AdminServer</name>

<self-tuning-thread-pool-size-min>30</self-tuning-thread-pool-size-min>

<listen-port>7001</listen-port>

<listen-address>XXX.XXX.XXX.XXX</listen-address>

</server>

• 起動オプション

-Dweblogic.SelfTuningThreadPoolSizeMin=30


TIPS

• 高負荷時に JDBC データソースの最大接続数を超えた取得が行われてしまう

• Why?

• 高負荷により自動チューニングでスレッド数が増えすぎている

• 最大スレッド数制約によるスレッド数の制限が必要

• 対応策

• 最大スレッド数制約にデータソース名を設定することが可能

• config.xml<max-threads-constraint>

<name>MaxThreadsConstraint-0</name>

<target>AdminServer</target>

<count>-1</count>

<connection-pool-name>AppDataSource</connection-pool-name>

</max-threads-constraint>

• データソースの最大接続数でスレッド数が制限される


TIPS

• Web アプリケーションが突然 503(Service Unavailable) エラーを返すようになった

• 対応策

• スレッドがスタックする原因を取り除く

• ワークマネージャでスレッドのスタックを無視するように設定

• ワークマネージャでスタックを検出する時間、スレッドの数を設定• config.xml

<work-manager>

<name>stuckthread_workmanager</name>

<work-manager-shutdown-trigger>

<max-stuck-thread-time>1200</max-stuck-thread-time>

<stuck-thread-count>2</stuck-thread-count>

</work-manager-shutdown-trigger>

</work-manager>

• Why?

• アプリケーションの処理でスレッドがスタックしている(BEA-000337 という ID のメッセージで確認可能)

• 過負荷防止のメカニズムにより、スレッドのスタックが検出されると、ワークマネージャがシャットダウンされる

• シャットダウンしたワークマネージャへのリクエストは 503 エラーで返る


参考資料

• ワークマネージャを使用したスケジューリング済み作業の最適化

• http://otndnld.oracle.co.jp/document/products/wls/docs103/config_wls/self_tuned.html

• WebLogic Server 9.0におけるワークロード（作業負荷）管理

• http://www.oracle.com/technology/global/jp/pub/articles/dev2arch/2006/01/workload-management.html

• トラブルシューティングガイドサポート診断パターン - 一般的なサーバハング

• http://support.oracle.co.jp/bea/support_patterns-ja/Generic_Server_Hang_Pattern.html

<Insert Picture Here>


Technology

WebLogic Server のアーキテクチャ(スレッド管理)