Administration Console オンライン ヘルプ
|
 |
 |
|
[JMS に関する属性と Administration Console 画面のリファレンス]
以下の節では、WebLogic JMS の管理パフォーマンス チューニング機能を実装することによってアプリケーションを最大限に活用する方法について説明します。
必要な場合は、以下の WebLogic JMS およびメッセージング ブリッジに関する節も参照してください。
以下の節では、WebLogic JMS の管理パフォーマンス チューニング機能を実装することによってアプリケーションを最大限に活用する方法について説明します。
WebLogic JMS ファイル ストアは、デフォルトで同期書き込みを使用することで最新のメッセージの整合性を保証します。通常、デフォルトの同期書き込みポリシーである [Cache-Flush] を無効にすると、ファイル ストアのパフォーマンスは大幅に向上します。その代わり、オペレーティング システムがクラッシュしたり、ハードウェアの障害が発生したりした場合には、メッセージがトランザクション対応であっても、送信したメッセージが失われたり、同じメッセージを重複して受信したりする可能性があります。オペレーティング システムでは通常のシャットダウン時に未処理の書き込みをすべてフラッシュするので、オペレーティング システムをシャット ダウンするだけではこうしたエラーは発生しません。こうしたエラーは、ビジー状態のサーバの電源を遮断することでエミュレートできます。
注意: ファイル ストアが非永続メッセージをディスクにページングするために排他的に使用されている場合、同期書き込みポリシーは無視されます。
デフォルトの [Cache-Flush] ポリシーを変更するには、次の手順に従います。
同期書き込みポリシーの詳細については、[JMS ファイル ストア] --> [コンフィグレーション]を参照してください。
[Direct-Write] ポリシーが設定されている場合、Solaris システムではトランザクションの信頼性はありますが、Windows システムではトランザクション データが直接ディスクに書き込まれずにオンディスク キャッシュに残される場合があります。この場合トランザクションに信頼性がないと見なされ、電源の障害が発生した場合にはオンディスク キャッシュのデータが失われて、その結果、メッセージが失われたり、同じメッセージが重複したりする可能性があります。Windows で [Direct-Write] を使用して信頼性のある書き込みを実現するには、ディスクの書き込みキャッシュをすべて無効にするか (デフォルトでは有効)、またはバッテリー バックアップ キャッシュのあるディスクを使用してください。ただし、ファイル システムによってはこの値を変更できません (たとえば、信頼性の高いキャッシュを持つ RAID システムなど)。
以下の表は、信頼性、パフォーマンス、およびスケーラビリティの点から同期書き込みポリシーを比較したものです。以下のキーを使用して、同期書き込みポリシー設定に基づく予想される結果を解釈してください。
以下の節では、JMS 接続ファクトリの属性をコンフィグレーションすることで分散送り先をチューニングする方法について説明します。
分散送り先のコンフィグレーションの詳細については、JMS 分散送り先のタスクを参照してください。
[JMS 接続ファクトリ｜コンフィグレーション｜一般] の [ロード バランスを有効化] 属性では、接続ファクトリを通じて作成された匿名でないプロデューサが、呼び出しごとに分散送り先内でロード バランシングされるかどうかを定義します。 分散送り先を使用して、複数の物理的送り先の間でプロデューサおよびコンシューマを分散またはバランシングするが、メッセージが生成されるたびにロード バランシングの決定を行いたくないアプリケーションでは、[ロード バランスを有効化] 属性をオフにできます。
分散送り先においてメッセージの負荷が適正に分散されるようにするには、プロデューサによって使用される初期の物理的な送り先 (キューまたはトピック) が、物理的な送り先メンバーによって常にランダムに選択される必要があります。
接続ファクトリでのロード バランシングをコンフィグレーションするには、次の手順に従います。
= True
Queue.sender.send() メソッドでは、分散キュー メンバー間での呼び出しごとに、匿名でないプロデューサがロード バランシングされます。 TopicPublish.publish() メソッドでは、[ロード バランスを有効化] 属性の設定にかかわりなく、匿名でないプロデューサが呼出しごとに常に同じ物理的なトピックに固定されます。= False
プロデューサは、失敗するまで同じ物理的送り先に対してメッセージを生成します。 失敗すると、新しい物理的送り先が選択されます。注意: 実装によっては、[サーバ アフィニティを有効化] 属性の設定が分散送り先のロード バランシング プリファレンスに影響することがあります。 詳細については、『Programming WebLogic JMS』の「[サーバ アフィニティを有効化] 属性を使用した場合の分散送り先ロード バランシングへの影響」を参照してください。
匿名プロデューサ (作成時に送り先を指定しないプロデューサ) は、送り先を切り替えるたびにロード バランシングされます。同じ送り先を使用し続けると、匿名でないプロデューサと同じ法則 (前述) が適用されます。
メッセージのロード バランシングが分散送り先のメンバー間でどのように行われるかについては、『Programming WebLogic JMS』の「分散送り先におけるメッセージのロード バランシング」を参照してください。
[JMS 接続ファクトリ｜コンフィグレーション｜一般] の [サーバ アフィニティを有効化] 属性では、分散送り先セット内の複数の物理的送り先にまたがってコンシューマまたはプロデューサのロード バランシングを実行するときに、同じ WebLogic Server で実行されている他の物理的送り先にまたがるロード バランシングを最初に試行するかどうかを定義します。
注意: [サーバ アフィニティを有効化] 属性は、キュー ブラウザには影響しません。 したがって、[サーバ アフィニティを有効化] が有効になっている場合でも、分散キューに作成されたキュー ブラウザをリモート分散キュー メンバーに固定できます。
接続ファクトリでサーバ アフィニティを無効化するには、次の手順に従います。
[サーバ アフィニティを有効化] の設定が分散送り先のメンバー間のロードバランシングにどのように影響するかについては、『Programming WebLogic JMS』の「[サーバ アフィニティを有効化] 属性を使用した場合の分散送り先ロード バランシングへの影響」を参照してください。
メッセージ ページング機能を使用すると、メッセージ負荷のピーク時に仮想メモリを開放できます。この機能は、大容量のメッセージ領域を使用するアプリケーションでは大きなメリットがあります。
JMS メッセージ ページングでは、永続メッセージと非永続メッセージのどちらの場合でも、永続メッセージがデータをメモリにキャッシュする場合にも、メモリが確保されます。ページングされた永続メッセージは通常のバッキング ストア (ファイルまたはデータベース) に引き続き書き込まれ、ページングされた非永続メッセージは個別にコンフィグレーションされた JMS サーバのメッセージ ページング ストアに書き込まれます。
メッセージがページングされても、消費されていたメモリはすべて解放されません。メッセージ ヘッダとメッセージ プロパティは、検索、ソート、およびフィルタ処理で使用するためメモリに残されます。
注意: トランザクション セッションで送信されたメッセージは、セッションがコミットされた後のページングでしか使用できません。 メッセージは、それ以前はメモリに保持されているだけです。したがって、アクティブなセッションがすべてコミットされるまでにクライアントの負荷量がピークに達しても問題ないよう、Java 仮想マシン (JVM) のヒープ サイズをチューニングしておく必要があります。 ヒープ サイズのチューニングの詳細については、『WebLogic Server パフォーマンス チューニング ガイド』の「Java 仮想マシン (JVM) のチューニング」を参照してください。
ページングをコンフィグレーションして有効にしない限り、すべてのメッセージ (永続メッセージも含む) はメモリに保持されます。ページングは、JMS サーバまたは特定の送り先を対象にコンフィグレーションできます。[JMS｜サーバ] ノードの属性を使用して、JMS サーバのページング ストアを指定したり、バイト ページングまたはメッセージ ページングを有効にしたり、ページングを開始および停止するバイト数またはメッセージ数の最大および最小しきい値をコンフィグレーションしたりできます。同様に、[送り先] ノードの属性を使用して、JMS サーバでコンフィグレーションされているすべてのトピックおよびキューのバイト ページングまたはメッセージ ページングをコンフィグレーションできます。送り先は、JMS サーバ用にコンフィグレーションされているページング ストアを使用します。
注意: メッセージ ページングはデフォルトで有効になっていません。ただし、メッセージ ページング ストアは、あらかじめコンフィグレーションしなくても、JMS サーバやその送り先でバイト ページングまたはメッセージ ページングを有効にすると自動的に作成されます。
また、JMS テンプレートを使用して複数の送り先をコンフィグレーションする場合、[テンプレート] ノードの属性を使用して、すべての送り先のページングをすばやくコンフィグレーションできます。特定の送り先に関してテンプレートのページング コンフィグレーションをオーバーライドする場合、どの送り先に対してもページングを有効または無効にできます。
新しい JMS サーバをコンフィグレーションする手順については、JMS サーバのタスク、JMS キューおよびトピック送り先のタスク、およびJMS テンプレートのタスクを参照してください。
注意: パフォーマンスをチューニングするために、ページングのしきい値をいつでも有効な値に変更できます。ただし、ページングを有効にすると、バイトまたはメッセージのしきい値を -1 にリセットすることでページングを動的に無効にすることはできません。ページングの発生を防ぐには、バイトまたはメッセージの上限しきい値を非常に大きい値 (最大値は 263 -1) に設定してページングが発生しないようにします。
各 JMS サーバには、JMS サーバとその送り先の非永続メッセージをページングするために排他的に使用される独自のページング ストアが必要です。JDBC ストアは相対的にパフォーマンスが低く実際には利点がないため、JMS JDBC ストアではなく JMS ファイル ストアを使用するのが最適です。
メッセージ ページング ストアは手動で作成できます。また、あらかじめコンフィグレーションしなくても、JMS サーバやその送り先でバイト ページングまたはメッセージ ページングを有効にすると自動的に作成されます。
新しいメッセージ ページング ストアをコンフィグレーションするには、次の手順に従います。
JMS ファイル ストア属性の詳細については、[JMS ファイル ストア] --> [コンフィグレーション]を参照してください。
既存の JMS サーバでページングをコンフィグレーションして有効にするには、次の手順に従います。
ページング ストアのコンフィグレーション手順については、JMS サーバのメッセージ ページング ストアのコンフィグレーションを参照してください。
注意: 各 JMS サーバは、それぞれ独自のページング ストアを使用する必要があります。
JMS テンプレートを使用すると、似た属性設定を持つ複数の送り先 (トピックまたはキュー) を効率的に定義できます。送り先用のテンプレートでページングをコンフィグレーションするには、次の手順に従います。
JMS テンプレートを使用しないで送り先のページングをコンフィグレーションする場合、次の手順に従います。
注意: JMS テンプレートを使用して送り先をコンフィグレーションした場合、送り先のバイト ページングまたはメッセージ ページングを明示的にコンフィグレーションすると、テンプレートのコンフィグレーションはオーバーライドされます。詳細については、送り先のコンフィグレーションによる JMS テンプレートのメッセージ ページングのオーバーライドおよびJMS テンプレートのタスクを参照してください。
テンプレートの設定をオーバーライドして特定の送り先のページングを有効または無効にする場合、次の手順に従います。
以下の節では、WebLogic Server JMS で使用可能なメッセージ ページング属性について簡単に説明します。
表 52-3 では、JMS サーバに対してメッセージ ページングをコンフィグレーションする際に定義するページング属性について説明します。他の JMS サーバ属性およびそれらの有効値とデフォルト値については、JMS テンプレートのタスクを参照してください。
|
非永続メッセージをページングする永続ストアの名前。ページング ストアは、永続メッセージまたは恒久サブスクライバ用のストアとは別に指定すること。 2 つの JMS サーバは同じページング ストアを使用することができないので、サーバごとに固有のページング ストアをコンフィグレーションする必要がある。 |
表 52-4 では、送り先に対して JMS テンプレートでのメッセージ ページングをコンフィグレーションする際に定義するページング属性について説明します。他の JMS テンプレート属性およびそれらの有効値とデフォルト値については、JMS テンプレートのタスクを参照してください。
表 52-5 では、送り先に関するメッセージ ページングをコンフィグレーションするときに定義するページング属性について説明します。他の JMS 送り先属性およびそれらの有効値とデフォルト値については、JMS キューおよびトピック送り先のタスクを参照してください。
注意: サーバのページングが有効で、送り先レベルのページングが指定した送り先に関して無効になっている場合でも、サーバのページングが開始されると、送り先のメッセージはページングされます。ただし、送り先レベルのページングが指定した送り先に関して無効になっている場合、送り先のメッセージがその送り先の最大しきい値を超えても、メッセージはページングされません。
表 52-6 では、JMS サーバ、JMS テンプレート、JMS 送り先で指定可能なバイト ページングおよびメッセージ ページングのしきい値について説明します。JMS サーバ、テンプレート、送り先の属性、およびそれらの有効値とデフォルト値については、JMS サーバのタスク、JMS キューおよびトピック送り先のタスク、およびJMS テンプレートのタスクを参照してください。
しきい値は、サーバ、テンプレート、および送り先に対して次のように定義します。
WebLogic JMS パフォーマンスのチューニングの詳細については、以下のヘルプ トピックを参照してください。
フロー制御機能を使うと、過負荷状態になっていると判断した JMS サーバや送り先は、メッセージ プロデューサの処理速度を遅くすることができます。
以下の節では、フロー制御の仕組みと、接続ファクトリでフロー制御をコンフィグレーションする方法について説明します。
JMS サーバやその送り先が指定のバイト数またはメッセージ数のしきい値を超えた場合、対処機能が作動し、メッセージ フロー (1 秒当たりのメッセージ数) を制限するようプロデューサに指示が出されます。
プロデューサは、JMS 接続ファクトリを通じてプロデューサ用にコンフィグレーションされた一連のフロー制御属性に基づき、プロダクション率を制限します。プロデューサは、指定した最大フローのメッセージ数から開始して、所定の間隔ごとに (たとえば、60 秒間、10 秒ごとに)、サーバや送り先がまだ対処機能を作動させたままであるかどうかを評価します。各間隔ごとに、サーバや送り先で対処機能が作動したままであれば、プロデューサは、所定のフロー最小値まで、プロダクション率を低下させます。
プロデューサの処理速度が低下するにつれ、しきい値条件は徐々に補正されます。これはサーバや送り先の対処機能が解除されるまで行われます。この時点で、プロデューサはプロダクション率を上げることができるようになりますが、必ずしも最大限まで上げる必要はありません。実際には、メッセージ フローは、所定の最大フローに達してフロー制御の対象でなくなる時点までは (サーバや送り先が対処機能を解除していても) 引き続き制御されます。
プロデューサは、セッションから一連のフロー制御属性を受信します。セッションは接続から、接続は接続ファクトリから、この属性を受信します。これらの属性により、プロデューサはメッセージ フローを調整できます。
具体的には、プロデューサはフローを最小値から最大値までの範囲内に制限する属性を受信します。プロデューサは、条件が悪くなると最小値側に移動し、改善されると最大値側に移動します。最小値側および最大値側への移行は、移行率を指定する 2 つの追加属性によって定義されます。また、最小値側および最大値側への移行の必要性は、コンフィグレーションされた間隔ごとに評価されます。
接続ファクトリでのメッセージ フロー制御をコンフィグレーションするには、次の手順に従います。
他の接続ファクトリ属性の詳細、およびそれらの有効値とデフォルト値については、JMS 接続ファクトリのタスクを参照してください。
バイト数またはメッセージ数のしきい値のコンフィグレーションに使用する属性は、JMS サーバまたはその送り先の一部として定義されます。表 52-8 に、上限しきい値と下限しきい値が JMS サーバまたは JMS 送り先のフロー制御を開始および停止する仕組みを示します。
他の JMS サーバ属性と JMS 送り先属性、およびそれらの有効値とデフォルト値についてはJMS サーバのタスクおよびJMS キューおよびトピック送り先のタスクを参照してください。
以下の節では、さらに 2 つのフロー制御機能について説明します。これらの機能を使用すると、メッセージ プロデューサが指定の最大メッセージ割り当てを超過したときにメッセージの送り先 (キューまたはトピック) への送信を一時的にブロックすることで、メッセージ割り当てエラーを回避できます。
[ブロッキング時の送信ポリシー] と [送信タイムアウト] 機能のコンフィグレーション手順については、以下を参照してください。
[送信タイムアウト] 機能を使用すると、送り先でスペースを利用できるようになるまでプロデューサが指定の時間にわたって待機できるので、メッセージ送信操作をより細かく制御できます。たとえば、プロデューサが要求を行い、十分なスペースが存在しない場合、プロデューサはスペースが利用可能になるまでブロックされるか、または操作がタイムアウトになります。
送り先がメッセージ割り当てを超過したときに JMS 接続ファクトリがメッセージ要求をブロックする時間を定義するには、次の手順に従います。
値を 0 に設定してブロッキング時の送信ポリシーを有効にしない場合、送り先で十分なスペースが利用できないときに「リソース割り当て」例外が発生します。
[送信タイムアウト] 属性の詳細については、[JMS 接続ファクトリ] --> [コンフィグレーション] --> [フロー制御]を参照してください。
ブロッキング時の送信ポリシーを使用すると、メッセージ割り当てを超過した送り先で複数のプロデューサによるスペースの競合が存在するときに、小さいメッセージを大きいメッセージより先に送信するかどうかに関する JMS サーバのブロック動作を定義できます。
送り先がメッセージ割り当てを超過したときに JMS サーバがメッセージ要求をブロックする方法を定義するには、次の手順に従います。
[ブロッキング時の送信ポリシー] 属性の詳細については、[JMS サーバ] --> [コンフィグレーション] --> [しきい値と割当]を参照してください。
WebLogic JMS パフォーマンスのチューニングの詳細については、以下のヘルプ トピックを参照してください。
以下の節では、メッセージの有効期限ポリシーとアクティブな有効期限処理という 2 つのメッセージ有効期限機能について説明します。これらの機能を使用すると、期限切れメッセージを検索する方法とそれらを検出したときの処理方法をより細かく制御できます。
旧リリースでは、WebLogic JMS はパッシブな有効期限ポリシーを実装していました。メッセージは検出された時点で期限切れとなり、システムから破棄されるだけでした。期限切れメッセージはアクティブに検索されなかったため、これらのメッセージがシステム上に蓄積され、システム リソースが消費される可能性がありました。アクティブなメッセージ有効期限を使用すると、期限切れメッセージを即座に消去することによってこうした問題を解決できます。さらに、期限切れメッセージの監査を使用すると、メッセージがいつ期限切れになったかをログに書き込むか、または期限切れメッセージを特別な送り先にリダイレクトすることによって期限切れメッセージを追跡できます。
有効期限ポリシーを使用して、メッセージが期限切れになったときに実行するアクションを定義します。[送り先] ノードの [有効期限ポリシー] では、送り先ごとに有効期限ポリシーを設定できます。[有効期限ポリシー] 属性を使用すると、期限切れメッセージの検出時に送り先で実行されるアクション (メッセージの破棄、メッセージの破棄とログへの書き込み、またはエラー送り先へのリダイレクト) を定義できます。
また、JMS テンプレートを使用して複数の送り先をコンフィグレーションする場合、[テンプレート] ノードの [有効期限ポリシー] 属性を使用して、すべての送り先の有効期限ポリシーをすばやくコンフィグレーションできます。特定の送り先に関するテンプレートの有効期限ポリシーをオーバーライドするには、その送り先の有効期限ポリシーを変更します。
有効期限ポリシーのコンフィグレーション手順については、以下のリンクをクリックしてください。
JMS テンプレートを使用せずにトピックの有効期限ポリシーをコンフィグレーションする場合は、次の手順に従います。特定のトピックに有効期限ポリシーを設定すると、JMS テンプレートに定義されている設定はオーバーライドされます。
トピックの [有効期限ポリシー] オプションの詳細については、[JMS トピック] --> [コンフィグレーション] --> [有効期限ポリシー]を参照してください。
[有効期限ログ ポリシー] の有効な値の詳細については、有効期限ログ ポリシーの定義を参照してください。
JMS テンプレートを使用せずにキューの有効期限ポリシーをコンフィグレーションする場合は、次の手順に従います。特定のキューに有効期限ポリシーを設定すると、JMS テンプレートに定義されている設定はオーバーライドされます。
キューの [有効期限ポリシー] オプションの詳細については、[JMS キュー] --> [コンフィグレーション] --> [有効期限ポリシー]を参照してください。
[有効期限ログ ポリシー] の有効な値の詳細については、有効期限ログ ポリシーの定義を参照してください。
JMS テンプレートを使用すると、似た属性設定を持つ複数の送り先 (トピックまたはキュー) を効率的に定義できます。このため、送り先用の既存のテンプレート上でメッセージ有効期限ポリシーをコンフィグレーションできます。
[有効期限ポリシー] オプションの詳細については、[JMS テンプレート] --> [コンフィグレーション] --> [有効期限ポリシー]を参照してください。
[有効期限ログ ポリシー] の有効な値の詳細については、有効期限ログ ポリシーの定義を参照してください。
[有効期限ポリシー] が [Log] に設定されている場合、[有効期限ログ ポリシー] で、メッセージに関するどの情報がログに書き込まれるかを定義します。[有効期限ログ ポリシー] の有効値は、%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 フィールドは常にログに書き込まれ、書き込みを無効にはできません。したがって、有効期限ポリシーが定義されていない ([None]) か、空の文字列として定義されている場合、ログ ファイルへの出力にはメッセージの 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 を入力します。期限切れメッセージは、検出時にシステムからパッシブに削除されます。
[有効期限スキャン間隔] の属性の詳細については、送り先をアクティブにスキャンして期限切れメッセージを処理するための JMS サーバのコンフィグレーションを参照してください。
|
|
|