サービス統合を使用するメッセージングのパフォーマンスの調整
パフォーマンスを最適化するため、 サービス統合テクノロジーを使用するようデプロイされたメッセージング・アプリケーションのパフォーマンスを制御する調整プロパティーを設定できます。
このタスクについて
サービス統合テクノロジーを使用するメッセージングのパフォーマンスを最適化するために、 以下の手順で示すように、管理コンソールを使用して各種のパラメーターを設定できます。これらのパラメーターは、wsadmin ツールを使用して設定することもできます。
z/OS® では、メッセージング・アプリケーションのパフォーマンスは、動的に変動するサーバントの数、およびサーバント間の処理の配分に影響されます。
サーバントの数およびサーバント間の処理配分の構成および管理について詳しくは、
アプリケーション・サービス提供環境のチューニングを参照してください。
手順
- 宛先の「使用可能なメッセージ数」を表示します。
宛先の「Available Message Count」を表示すると、メッセージ・コンシューマーが現在のワークロードを処理できるかどうかを判別できます。特定の宛先で使用可能なメッセージ数が多すぎるか、 時間とともに増加する場合、このトピックに記載した調整に関する推奨事項を考慮してください。
- キューの AvailableMessageCount 統計を使用可能にします。 管理サーバーを再始動した場合は、AvailableMessageCount 統計を再度使用可能に設定します。
これは、サーバーが再始動されると、これらのランタイム設定が保持されないためです。
- ナビゲーション・ペインで、「「リソース」 > 「JMS」->「JMS プロバイダー (JMS providers)」」をクリックします。
- 目次ペインで、「server_name」をクリックします。
- 「ランタイム」タブをクリックします。
- 「現在モニターされている統計セット」で「カスタム」をクリックします。
- 「カスタム・モニター・レベル」パネルで、「SIB サービス」 > 「SIB メッセージング・エンジン」 > 「engine_name」 > 「宛先」 > 「キュー」 > 「queue_name」をクリックします。
- AvailableMessageCount オプションを選択します。
- 「使用可能」をクリックします。
- キューに使用可能なメッセージ数を表示します。
- ナビゲーション・ペインで、「「リソース」 > 「JMS」->「JMS プロバイダー (JMS providers)」」をクリックします。
- 目次ペインで、「server_name」をクリックします。
- 「パフォーマンス・モジュール」 > 「SIB サービス」 > 「SIB メッセージング・エンジン」 > 「engine_name」 > 「宛先」 > 「キュー」 > 「queue_name」をクリックします。
- 「リソース選択」パネル上部の「モジュールの表示」をクリックします。これにより、右側にある「データ・モニター」パネルに AvailableMessageCount データが表示されます。
「データ・モニター」パネルを使用して、モニター・データの収集を管理できます。 例えば、ボタンを使用してロギングを開始および停止する、 またはデータをテーブルとして表示するかグラフとして表示するかを変更することなどが可能です。
- キューの AvailableMessageCount 統計を使用可能にします。 管理サーバーを再始動した場合は、AvailableMessageCount 統計を再度使用可能に設定します。
これは、サーバーが再始動されると、これらのランタイム設定が保持されないためです。
1 つ以上のメッセージング・エンジンをホスティングしているアプリケーション・サーバー に、必要なメッセージ・スループットに適した量のメモリーが備わっていることを確認します。
サーバーをメッセージング・バスに追加する際、つまり、メッセージング・エンジンを作成するときに、Java™ 仮想マシン (JVM) の初期ヒープ・サイズと 最大ヒープ・サイズを調整することができます。この調整を行うという 選択が可能なのは、以下の場合です。- 単一サーバーをバスに追加するとき
- クラスターをバスに追加するとき
- 新規サーバーを、それ自体がバス・メンバーである既存のクラスターに追加するとき
少なくとも 1 つのバスのバス・メンバーであるか、または、少なくとも 1 つのバスのバス・メンバーである クラスターのメンバーであるアプリケーション・サーバーの 場合、推奨される初期ヒープ・サイズおよび最大ヒープ・サイズ は 768MB です。
クラスターをバスに追加する場合は、そのクラスター内のすべてのサーバーについて、JVM 初期ヒープ・サイズおよび最大ヒープ・サイズを 768 MB に増やすことをお勧めします。
- 初期ヒープ・サイズを増やすと、平均メッセージ・サイズが小さい場合に パフォーマンスが向上します。
- 最大ヒープ・サイズを増やすと、平均メッセージ・サイズが比較的大きい場合に パフォーマンスが向上します。
- OutOfMemoryError 例外の発生を減らします。
サービス統合バスによってトランザクション内で処理されるメッセージ・セットの累積サイズが JVM ヒープを使い切るほど大きい場合、 OutOfMemoryError 例外が発生します。 1 つのトランザクション内で大きなメッセージ・セットを処理する際 の OutOfMemoryError 例外の発生数を減らすため、以下のいずれかの オプションを検討してください。
- アプリケーション・サーバーの JVM ヒープ・サイズを増やします。
ピークのアクティビティー期間中に、 メッセージング・エンジンのフェイルオーバー・プロセスを処理するために十分なヒープ・サイズをメッセージング・エンジンに確保することが重要です。 このことは、JVM ヒープがほぼ使い尽くされたときに、 メッセージング・エンジンがクラスター・メンバー環境内の別のインスタンスにフェイルオーバーする際にも適用されます。 こうした状況では、フェイルオーバーの場合にメッセージング・エンジンをホストするのに適格なクラスター・メンバーごとに最大ヒープ・サイズの値を約 512 MB 増やす必要があります。例えば、WebSphere Application Server on z/OS では、JVM ヒープをほぼ使い尽くすような状態で実行している場合は、メッセージング・エンジンに関連付けられたクラスター・メンバーについて付属のヒープ値を 512 MB 増やす必要があります。
- トランザクション内で処理されるメッセージ・セットの累積サイズを減らします。
- アプリケーション・サーバーの JVM ヒープ・サイズを増やします。
- メッセージの信頼性レベルを調整します。 メッセージに対して選択された信頼性レベルは、パフォーマンスに重大な影響を及ぼします。 パフォーマンスの低下を基準に信頼性レベルを並べると、次のようになります (下に行くほど、パフォーマンスは低下)。
- ベスト・エフォート非パーシスタント
- 高速非パーシスタント
- 高信頼性非パーシスタント
- 高信頼性パーシスタント
- 保証パーシスタント


http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tjn0026_
ファイル名:tjn0026_.html