WebLogic JMS のコンフィグレーションと管理
|
 |
 |
|
以下の節では、WebLogic JMS の管理パフォーマンス チューニング機能を実装することによってアプリケーションを最大限に活用する方法について説明します。
JMS 送り先のチューニング オプションである [メッセージング パフォーマンスのオプション] を使用すると、送り先でメッセージ処理を調整できます。JMS 送り先には、メッセージをバッチにまとめてコンシューマへ配信することにより、自動的にパフォーマンスを最適化しようとする内部アルゴリズムがあります。メッセージ レートや他の要因の変化に応じて、こうしたアルゴリズムでバッチのサイズや配信時間が変更されます。ただし、このようなアルゴリズムですべてのメッセージング環境のパフォーマンスを最適化することはできません。[メッセージング パフォーマンスのオプション] を指定することで、メッセージ レートや他の要因の変更に応じたアルゴリズムの対応方法を変更して、システムのパフォーマンスを調整できます。
[メッセージング パフォーマンスのオプション] には、以下のコンフィグレーション パラメータがあります。
たとえば、並列する多数のメッセージ コンシューマが設定されたキューの場合、Administration Console で [スループットよりもレイテンシを最大限優先] という値を選択 (または DestinationBean MBean に「0」を指定) すると、そのキューではコンシューマが利用可能になるとすぐに、できるだけ早くコンシューマにメッセージを送出しようとします。反対に、迅速な応答が求められないメッセージ コンシューマが 1 つだけ設定されているキューの場合、Administration Console で [レイテンシよりもスループットを最大限優先] という値を選択 (または DestinationBean MBean に「100」を指定) すると、そのキューではメッセージをバッチの形でのみコンシューマに送出しようとし、結果として待機時間は増加しますが、送出回数が少なくなるのでサーバ全体のスループットが向上します。
JMS 送り先のコンフィグレーションの詳細については、「キューおよびトピック送り先リソース」を参照してください。
[メッセージング パフォーマンスのオプション] は、非同期メッセージ パイプラインを使用する非同期コンシューマに対応しています。また、同期コンシューマのプリフェッチ モード機能 (非同期メッセージ パイプラインの模擬機能) を使用する同期コンシューマにも対応します。ただし、[最大メッセージ数] に設定されている値が小さすぎると、送り先のパフォーマンス アルゴリズムの影響が無効になる場合があります。
詳細については、『WebLogic JMS プログラマーズ ガイド』の「メッセージの受信」を参照してください。
以前のリリースでは、複数のレベルの割り当てがありました。送り先には独自の割り当てがあり、同時に JMS サーバ内の割り当てをめぐって競合する必要もありました。このリリースでは、割り当てのレベルは 1 つのみです。送り先では、独自のプライベートの割り当てを使用することも、共有割り当てを使用して他の送り先と競合することもできます。
独自の割り当てを定義する送り先は、JMS サーバの割り当てのスペースを共有しません。JMS サーバでは、引き続きメッセージとバイトの割り当てを直接コンフィグレーションできますが、これらのオプションは割り当てリソースを参照しない送り先の割り当てを定義するためにのみ使用できます。
割り当てとは、コンフィグレーション可能な名前付きの JMS モジュール リソースです。割り当てでは、メッセージおよびバイトの最大数を定義します。これを 1 つまたは複数の送り先に関連付けることで、定義した最大数を強制することができます。同じ割り当てを参照する複数の送り先は、割り当てリソースの共有ポリシーに従ってその割り当てを共有します。
割り当てリソースでは、以下のパラメータをコンフィグレーションできます。
|
|
|
|
|
|
|
|
割り当てのコンフィグレーション パラメータの詳細については、『WebLogic Server MBean リファレンス』の「QuotaBean」を参照してください。Administration Console を使用して割り当てリソースをコンフィグレーションする手順については、Administration Console オンライン ヘルプの「送り先に対する割り当ての作成」を参照してください。
送り先では、割り当てのバイトおよびメッセージの最大数は定義しないことになりました。代わりに、これらの値を定義した割り当てリソースと、共有および競合に関する割り当てポリシーを使用できます。
送り先の [割り当て] パラメータでは、その送り先に割り当てを強制するためにどの割り当てリソースを使用するかを定義します。この値は動的で、いつでも変更できます。ただし、割り当てリソースを変更した時点でその割り当ての未処理リクエストがあると、それらのリクエストが javax.jms.ResourceAllocationException で失敗します。
注意 : 割り当ての未処理リクエストは、割り当てリソースが変更されたときに失敗します。これは、送り先の割り当てを他の割り当てに切り替えたときに失敗することを意味し、割り当てリソースのメッセージ属性やバイト属性を変更したときには失敗しません。
送り先で割り当てをコンフィグレーションしない場合もあります。JMS サーバの割り当てを使用すると、これらの「割り当てをコンフィグレーションしていない」送り先で使用するリソースを制限できます。[割り当て] 属性が明示的に設定されていないすべての送り先は、それらがデプロイされている JMS サーバの割り当てを共有します。この場合の動作は、[共有] パラメータが有効になっている各 JMS サーバに特別な割り当てリソースが定義されている場合とまったく同じです。
JMS サーバの割り当てのインタフェースは、以前のリリースから変更されていません。JMS サーバの割り当ては、JMSServerMBean のメソッドを使用して完全に制御できます。JMS サーバの割り当ての割り当てポリシーは、JMS サーバで [ブロッキング時の送信ポリシー] パラメータを使用して設定します。詳細については、「JMS サーバに対するブロッキング時の送信ポリシーの指定」を参照してください。JMS サーバの割り当ての割り当てポリシーも、他の割り当てのポリシー設定と同じように機能します。
ブロッキング時の送信ポリシーを使用すると、メッセージ割り当てを超過した送り先で複数のプロデューサによるスペースの競合が存在するときに、小さいメッセージを大きいメッセージより先に送信するかどうかに関する JMS サーバのブロック動作を定義できます。
Administration Console を使用して、送り先がメッセージ割り当てを超過したときに JMS サーバがメッセージ要求をブロックする方法を定義するには、次の手順に従います。
[ブロッキング時の送信ポリシー] フィールドの詳細については、Administration Console オンライン ヘルプの「JMS サーバ : コンフィグレーション : しきい値と割り当て」を参照してください。
[送信タイムアウト] 機能を使用すると、送り先でスペースを利用できるようになるまで指定の時間にわたってメッセージの生成を待機できるため、メッセージ送信処理をより細かく制御できます。たとえば、プロデューサがリクエストを行い、十分なスペースが存在しない場合、プロデューサはスペースが利用可能になるまでブロックされるか、または処理がタイムアウトになります。
Administration Console を使用して、送り先がメッセージの最大割り当てを超過したときに JMS 接続ファクトリがメッセージのリクエストをブロックする時間を定義するには、次の手順に従います。
値を 0 に設定してブロッキング時の送信ポリシーを有効にしない場合、送り先で十分なスペースが利用できないときに「リソース割り当て」例外が発生します。
[送信タイムアウト] フィールドの詳細については、Administration Console オンライン ヘルプの「JMS 接続ファクトリ : コンフィグレーション : フロー制御」を参照してください。
ディスク スペースを節約しながら JVM 境界にまたがってやりとりされるメッセージの送信パフォーマンスを向上させるため、ユーザ指定のしきい値サイズを超過したメッセージの自動圧縮を指定できます。メッセージの圧縮を使用すると、ネットワークを介して送信されるメッセージのサイズを自動的に小さくすることで、ネットワークのボトルネックを緩和できます。また、ファイル ストアやデータベースに永続メッセージを格納する際のディスク スペースも節約できます。
注意 : メッセージの種類によっては、圧縮によって実際にはサイズが大きくなることがあるため、圧縮されたメッセージが送り先の割り当てに影響するおそれがあります。
メッセージ圧縮のしきい値は、WLMessageProducer インタフェースの JMS API 拡張機能を使用することによってプログラム的に設定するか、接続ファクトリまたは SAF リモート コンテキストで [デフォルト圧縮しきい値] を指定することによって管理的に設定できます。
Administration Console を使用してデフォルト圧縮しきい値をコンフィグレーションする手順については、以下を参照してください。
コンフィグレーションされたメッセージ圧縮は、クライアント送信の場合はプロデューサ、メッセージ受信またはメッセージ ブラウズの場合は接続ファクトリに対して、または SAF 転送を通じて実行されます。メッセージは GZIP で圧縮されます。圧縮は、メッセージのプロデューサとコンシューマが別々のサーバ インスタンスに配置されていてメッセージが JVM 境界をまたぐ場合 (通常は、WebLogic ドメインが別のマシンにあってネットワーク接続をまたぐ場合) にのみ発生します。解凍は、メッセージのコンテンツがアクセスされたときに、クライアント サイドで自動的に発生します。ただし、以下の状況でも解凍が発生します。
サーバ サイドでは、ディスクに書き込まれるときでも、メッセージは常に圧縮されたままです。
メッセージ ページング機能を使用すると、メッセージ負荷のピーク時に JMS サーバによって自動的に仮想メモリの開放が試行されます。この機能は、大容量のメッセージ領域を使用するアプリケーションでは大きなメリットがあります。JMS サーバでは常にメッセージ ページングが有効になっており、メッセージ ページング ディレクトリは自動的に作成されるためコンフィグレーションする必要はありません。ただし、[ページング ディレクトリ] オプションを使用してディレクトリを指定することもでき、その場合はページングされたメッセージがこのディレクトリ内のファイルに書き込まれます。
JMS メッセージ ページングでは永続メッセージのデータがメモリにキャッシュされるため、永続メッセージ用のメモリを節約できます。JMS サーバがファイル ストア (ユーザ定義のストアまたはサーバのデフォルト ストア) に関連付けられている場合、ページングされた永続メッセージは通常はそのファイル ストアに書き込まれます。一方、非永続メッセージは、常に JMS サーバのページング ディレクトリに書き込まれます。JMS サーバが JDBC ストアに関連付けられている場合は、ページングされた永続メッセージと非永続メッセージの両方が常に JMS サーバのページング ディレクトリに書き込まれます。
しかし、メッセージのヘッダは検索、ソート、フィルタ処理のためメモリに残されるため、メッセージをページングすることでそのメッセージが消費していたメモリをすべて開放できるわけではありません。ただし、ユーザ プロパティは例外で、メッセージの本文と一緒にページングされます。
注意 : コンシューマが受信したメッセージがまだ確認応答されていない場合は、セッションがコミットされた後にのみそのメッセージをページングすることができます。メッセージは、それ以前はメモリに保持されているだけです。したがって、アクティブなセッションがすべてコミットされるまでにクライアントの負荷量がピークに達しても問題ないよう、Java 仮想マシン (JVM) のヒープ サイズをチューニングしておく必要があります。
ページング ディレクトリが指定されていない場合、ページングされたメッセージの本文はドメインのルート ディレクトリの servername サブディレクトリ内にある、デフォルトの \tmp ディレクトリに書き込まれます。たとえば、デフォルトのページング ディレクトリが指定されていない場合、次のディレクトリがデフォルトになります。
bea_home\user_projects\domains\domainname\servers\servername\tmp
domainname はドメインのルート ディレクトリ (通常は c:\bea\user_projects\domains\domainname) です。これは、WebLogic Server プログラム ファイルが格納されるディレクトリ (通常は c:\bea\weblogic90) に対応するディレクトリです。
[メッセージ バッファ サイズ] オプションでは、ディスクにページングされる前のメモリ内のメッセージ本文を保存するために使用するメモリの量を指定します。[メッセージ バッファ サイズ] のデフォルト値は、JVM の最大ヒープサイズのおよそ 3 分の 1、または最大値の 512 MB になります。このパラメータの設定値を大きくするほど、多くのメッセージがキューまたはトピックに待機している際に JMS でより多くのメモリが消費されます。このしきい値を超えると、JMS はメモリ使用量をしきい値未満に抑えようとして、[ページング ディレクトリ] オプションで指定したディレクトリに、メッセージ本文を書き込むことがあります。
このパラメータは割り当てではない点に注意してください。サーバ上のメッセージ数がしきい値を超えると、サーバはメッセージをディスクに書き込み、できるだけ速やかにメモリから削除してメモリ使用量を減らします。ただし、新しいメッセージの受信を休止することはありません。それでも、メッセージ受信速度がページング速度を上回る場合は、メモリ不足になる可能性があります。メッセージ負荷の大きいユーザができるかぎり高い可用性をサポートするには、割り当てを設定するか、しきい値を設定してフロー制御を有効にすることで、サーバ上でのメモリ使用量を減らすことを検討してください。
フロー制御機能を使うと、過負荷状態になっていると判断した JMS サーバや送り先は、メッセージ プロデューサの処理速度を遅くすることができます。
以下の節では、フロー制御の仕組みと、接続ファクトリでフロー制御をコンフィグレーションする方法について説明します。
JMS サーバやその送り先が指定のバイト数またはメッセージ数のしきい値を超えた場合、対処機能が作動し、メッセージ フロー (1 秒当たりのメッセージ数) を制限するようプロデューサに指示が出されます。
プロデューサは、JMS 接続ファクトリを通じてプロデューサ用にコンフィグレーションされた一連のフロー制御属性に基づき、プロダクション率を制限します。プロデューサは、指定した最大フローのメッセージ数から開始して、所定の間隔ごとに (たとえば、60 秒間、10 秒ごとに)、サーバや送り先がまだ対処機能を作動させたままであるかどうかを評価します。間隔ごとに、サーバや送り先で対処機能が作動したままであれば、プロデューサは、所定のフロー最小値まで、プロダクション率を低下させます。
プロデューサの処理速度が低下するにつれ、しきい値条件は徐々に補正されます。これはサーバや送り先の対処機能が解除されるまで行われます。この時点で、プロデューサはプロダクション率を上げることができるようになりますが、必ずしも最大限まで上げる必要はありません。実際には、メッセージ フローは、所定の最大フローに達してフロー制御の対象でなくなる時点までは (サーバや送り先が対処機能を解除していても) 引き続き制御されます。
プロデューサは、セッションから一連のフロー制御属性を受信します。セッションは接続から、接続は接続ファクトリから、この属性を受信します。これらの属性により、プロデューサはメッセージ フローを調整できます。
具体的には、プロデューサはフローを最小値から最大値までの範囲内に制限する属性を受信します。プロデューサは、条件が悪くなると最小値側に移動し、改善されると最大値側に移動します。最小値側および最大値側への移行は、移行率を指定する 2 つの追加属性によって定義されます。また、最小値側および最大値側への移行の必要性は、コンフィグレーションされた間隔ごとに評価されます。
フロー制御フィールドの詳細、およびその有効値とデフォルト値については、Administration Console オンライン ヘルプの「JMS 接続ファクトリ : コンフィグレーション : フロー制御」を参照してください。
バイト数またはメッセージ数のしきい値のコンフィグレーションに使用する属性は、JMS サーバまたはその送り先の一部として定義されます。表 9-4 に、上限しきい値と下限しきい値が JMS サーバまたは JMS 送り先のフロー制御を開始および停止する仕組みを示します。
JMS サーバおよび送り先のその他のしきい値フィールドと割り当てフィールドの詳細、およびそれらの有効値とデフォルト値については、Administration Console オンライン ヘルプの以下のページを参照してください。
以下の節では、メッセージの有効期限ポリシーとアクティブな有効期限処理という 2 つのメッセージ有効期限機能について説明します。これらの機能を使用すると、期限切れメッセージを検索する方法とそれらを検出したときの処理方法をより細かく制御できます。
アクティブなメッセージ有効期限を使用すると、期限切れメッセージが即座に消去されます。さらに、期限切れメッセージの監査を使用すると、メッセージがいつ期限切れになったかをログに書き込むか、または期限切れメッセージを定義済みの「エラー」送り先にリダイレクトすることによって期限切れメッセージを追跡できます。
有効期限ポリシーを使用して、メッセージが期限切れになったときに実行するアクションを定義します。[送り先] ノードの [有効期限ポリシー] では、送り先ごとに有効期限ポリシーを設定できます。[有効期限ポリシー] 属性を使用すると、期限切れメッセージの検出時に送り先で実行されるアクション (メッセージの破棄、メッセージの破棄とログへの書き込み、またはエラー送り先へのリダイレクト) を定義できます。
また、JMS テンプレートを使用して複数の送り先をコンフィグレーションする場合、[有効期限ポリシー] フィールドを使用して、すべての送り先の有効期限ポリシーをすばやくコンフィグレーションできます。特定の送り先に関するテンプレートの有効期限ポリシーをオーバーライドするには、その送り先の有効期限ポリシーを変更します。
有効期限ポリシーのコンフィグレーション手順については、以下のリンクをクリックしてください。
JMS テンプレートを使用せずにトピックの有効期限ポリシーをコンフィグレーションする場合は、次の手順に従います。特定のトピックに有効期限ポリシーを設定すると、JMS テンプレートに定義されている設定はオーバーライドされます。
トピックの有効期限ポリシー オプションの詳細については、Administration Console オンライン ヘルプの「JMS トピック : コンフィグレーション : 配信の失敗」を参照してください。
有効な有効期限ログ ポリシーの値の詳細については、「有効期限ログ ポリシーを定義する」を参照してください。
JMS テンプレートを使用せずにキューの有効期限ポリシーをコンフィグレーションする場合は、次の手順に従います。特定のキューに有効期限ポリシーを設定すると、JMS テンプレートに定義されている設定はオーバーライドされます。
キューの有効期限ポリシー オプションの詳細については、Administration Console オンライン ヘルプの「JMS キュー : コンフィグレーション : 配信の失敗」を参照してください。
有効な有効期限ログ ポリシーの値の詳細については、「有効期限ログ ポリシーを定義する」を参照してください。
JMS テンプレートを使用すると、似た属性設定を持つ複数の送り先 (トピックまたはキュー) を効率的に定義できます。このため、送り先用の既存のテンプレート上でメッセージ有効期限ポリシーをコンフィグレーションできます。
テンプレートの有効期限ポリシー オプションの詳細については、Administration Console オンライン ヘルプの「JMS テンプレート : コンフィグレーション : 配信の失敗」を参照してください。
有効な有効期限ログ ポリシーの値の詳細については、「有効期限ログ ポリシーを定義する」を参照してください。
注意 : [有効期限ログ ポリシー] パラメータはこのリリースの WebLogic Server では非推奨となっています。代わりに、メッセージ ライフ サイクルのロギング機能を使用することをお勧めします。この機能を使用すると、JMS サーバに届いた JMS メッセージに発生する基本的なイベントを、詳細な有効期限データも含め包括的に把握できます。メッセージ ライフ サイクルのロギングの詳細については「メッセージ ライフ サイクルのロギング」を参照してください。
[有効期限ポリシー] が [ログ] に設定されている場合、[有効期限ログ ポリシー] で、メッセージに関するどの情報がログに書き込まれるかを定義します。[有効期限ログ ポリシー] の有効値は、%header%、%properties%、JMS 仕様で定義されている JMS ヘッダ プロパティ、WebLogic JMS 固有の拡張ヘッダ フィールドの JMSDeliveryTime と JMSRedeliveryLimit、およびユーザ定義のプロパティです。各プロパティは、カンマで区切る必要があります。
%header% 値は、ヘッダ フィールドがログに書き込まれることを示します。%properties% 値は、ユーザ プロパティがログに書き込まれることを示します。どちらの値も、大文字と小文字は区別されません。ただし、個別の JMS ヘッダ フィールドおよびユーザ プロパティの列挙値は、大文字と小文字が区別されます。
JMSPriority、Name、Address、City、State、Zip%header%、Name、Address、City、State、ZipJMSCorrelationID、%properties%JMSMessageID フィールドは常にログに書き込まれ、書き込みを無効にはできません。したがって、有効期限ポリシーが定義されていない ([なし]) か、空の文字列として定義されている場合、ログ ファイルへの出力にはメッセージの JMSMessageID のみが含まれます。
期限切れメッセージがログに書き込まれる場合、メッセージのテキスト部分 (タイムスタンプ、重大度、スレッド情報、セキュリティ ID などを除く) は以下のフォーマットに準拠します。
<ExpiredJMSMessage JMSMessageId='$MESSAGEID' >
<HeaderFields Field1='Value1' [Field2='Value2'] ] />
<UserProperties Property1='Value1' [Property='Value2'] ] />
</ExpiredJMSMessage>
$MESSAGEID は Message.getJMSMessageID () によって返される文字列です。
<ExpiredJMSMessage JMSMessageID='ID:P<851839.1022176920343.0' >
<HeaderFields JMSPriority='7' JMSRedelivered='false' />
<UserProperties Make='Honda' Model='Civic' Color='White'
Weight='2680' />
</ExpiredJMSMessage>
ヘッダ フィールドが表示されない場合、ヘッダ フィールド行は表示されません。ユーザ プロパティが表示されない場合、その行は表示されません。ヘッダ フィールドとプロパティが存在しない場合、開始タグは閉じ括弧 (/>) で閉じることができるので終了タグ </ExpiredJMSMessage> は必要ありません。
<ExpiredJMSMessage JMSMessageID='ID:N<223476.1022177121567.1' />
すべての値は引用符で区切られます。すべての文字列値は 32 文字に制限されます。要求されたフィールドまたはプロパティが存在しない場合、それらは表示されません。要求されたフィールドまたはプロパティが存在するが値がない (null 値) 場合、それらは null として (単一引用符なしで) 表示されます。要求されたフィールドまたはプロパティが空文字の場合、それらは 1 組の単一引用符 (間にスペースなし) として表示されます。
<ExpiredJMSMessage JMSMessageID='ID:N<851839.1022176920344.0' >
<UserProperties First='Any string longer than 32 char ...'
Second=null Third='' />
</ExpiredJMSMessage>
アクティブな有効期限処理機能を使用すると、期限切れメッセージをそれが送信またはパブリッシュされた送り先から削除するタイミングを定義できます。メッセージは必ずしも有効期限に削除されず、ユーザ定義の秒数以内に削除されます。秒数が少ないほど、メッセージの削除が実際の有効期限に近づきます。
JMS サーバが送り先をアクティブにスキャンして期限切れメッセージを処理する方法を定義するには、次の手順に従います。デフォルト値は 30 秒です。つまり、JMS サーバは各スキャンの間で 30 秒待機します。
アクティブなスキャンを無効にするには、0 を入力します。期限切れメッセージは、検出時にシステムからパッシブに削除されます。
[有効期限スキャン間隔] 属性の詳細については、Administration Console オンライン ヘルプの「JMS サーバ : コンフィグレーション : 全般」を参照してください。
|
|
|