|
| |
| Sun Java System Message Queue 3.5 SP1 管理ガイド | |
第 9 章
メッセージサービスの分析と調整この章では、Message Queue サービスの分析と調整を行い、メッセージングアプリケーションのパフォーマンスを最適化する方法に関連するさまざまなトピックを取り上げます。次のトピックが含まれます。
パフォーマンス関連パフォーマンス調整プロセス
メッセージングアプリケーションのパフォーマンスは、アプリケーションと Message Queue サービスの相互関係に左右されます。そのため、パフォーマンスを最大化するには、アプリケーション開発者と管理者が協力し合う必要があります。
パフォーマンスを最適化するプロセスは、アプリケーションの設計から始まります。アプリケーションが配置された後も、継続してメッセージサービスの調整を行います。パフォーマンス調整プロセスには、次の段階があります。
通常は、上記に概略したプロセスを繰り返し実行します。アプリケーションの配置時に、Message Queue 管理者は、メッセージサーバの適合性を評価し、アプリケーションの全般的なパフォーマンス要件を満たしているかどうかを判断します。ベンチマークテストがこれらの要件を満たす場合は、この章で説明するとおり、管理者はシステムの調整段階に入ることができます。一方、ベンチマークテストがパフォーマンス要件を満たしていない場合は、アプリケーションの再設計や配置アーキテクチャの変更が必要となる場合があります。
パフォーマンスのさまざまな側面
一般に、パフォーマンスの基準は、メッセージサービスがプロデューサからコンシューマへメッセージを配信するときの速度と効率です。ただし、パフォーマンスには、ニーズに応じて重要度が変わるさまざまな側面があります。
コネクションの負荷 メッセージプロデューサまたはメッセージコンシューマの数、もしくは、システムがサポート可能な同時コネクションの数
メッセージのスループット メッセージングシステムが 1 秒間に扱えるメッセージ数、またはメッセージのバイト数
遅延 特定のメッセージがメッセージプロデューサからメッセージコンシューマへ配信されるまでに要する時間
安定性 メッセージサービス全体の可用性、つまり過負荷や障害による影響をどれだけ抑えられるか
効率 メッセージ配信の効率。使用するコンピュータリソースに関係する、メッセージスループットの評価
パフォーマンスのこれらの異なる評価基準は、一般に相互に関連しています。メッセージスループットが高い場合、メッセージがメッセージサーバへバックログされることは、ほとんどありません。その結果、遅延も短くなり、シングルメッセージはすぐに配信されます。ただし、遅延はさまざまな要因に左右されます。そのような要因の例としては、通信リンクの速度、メッセージサーバの処理速度、クライアントの処理速度などがあります。
どのような場合でも、パフォーマンスには複数の異なる側面があります。一般に、その中でどれがもっとも重要となるかは、特定のアプリケーションの要件によって決まります。
ベンチマーク
ベンチマークとは、使用中のメッセージングアプリケーション用のテスト群を作成し、このテスト群を用いてメッセージスループットや、そのほかの観点からパフォーマンスを評価するプロセスです。
たとえば、複数のプロデューシングクライアントを対象に、複数の、コネクション、セッション、メッセージプロデューサを使用し、標準サイズの持続的または持続性のないメッセージを一部のキューやトピック (すべてメッセージングアプリケーションの設計に依存) へ一定レートで送信するテスト群を作成できます。同様に、複数の、コネクション、セッション、および特定タイプのメッセージコンシューマを使用し、特定の通知モードでメッセージをコンシュームする複数のコンシューミングクライアントをテスト群に含められます。
標準のテスト群を使用することで、メッセージがプロデュースされてからコンシュームされるまでに要する時間やメッセージの平均スループットレートを測定したり、システムを監視して、コネクションスレッド使用率、メッセージストレージデータ、メッセージフローデータ、そのほかの関連するメトリックスを監視したりできます。その後、パフォーマンスに悪影響が出る上限まで、メッセージのプロデュースレート、メッセージプロデューサの数、その他の変数を増加させることができます。実現可能な最大スループットが、メッセージサービス設定のベンチマークになります。
このベンチマークを基に、テスト群の特性の一部を変更できます。パフォーマンスに影響しそうな要因すべてを慎重に制御すれば (「パフォーマンスに影響するアプリケーション設計の要因」を参照)、これらの要因の変化によるベンチマークへの影響を理解できます。たとえば、コネクション数またはメッセージ数を 5 倍もしくは 10 倍に増やし、パフォーマンスに与える影響を調べることができます。
逆に、アプリケーションベースの要因を一定に保ち、たとえば、コネクションプロパティ、スレッドプールプロパティ、JVM メモリー制限、制限の動作、組み込み持続とプラグイン持続などを変更するといった、制御方法でブローカ設定を変更して、これらの変更がパフォーマンスに及ぼす影響を判断することもできます。
アプリケーションのこのようなベンチマークから、メッセージサービスを調整して配置済みのアプリケーションのパフォーマンスを向上させたいときに有用な情報を得られます。ベンチマークによって、1 か所の変更や一連の変更による影響を正確に予測できます。
原則として、ベンチマークは、管理されたテスト環境で、メッセージサービスを安定させるため長期間実施する必要があります。Java コードをマシンコードに変換する JIT コンパイルによる起動時には、パフォーマンスに悪影響が及びます。
基準になる使用パターン
メッセージングアプリケーションが配置され稼働された後は、基準になる使用パターンを確立することが重要となります。要求のピークがいつ発生するか把握し、その要求の定量化を図ります。たとえば、通常、要求はエンドユーザー数、アクティビティレベル、時間帯、またはこれらすべてによって左右されます。
基準になる使用パターンを確立するには、十分長い期間メッセージサーバを監視し、コネクション数、ブローカまたは特定の送信先に格納されたメッセージ数、ブローカまたは特定の送信先との間のメッセージフロー、アクティブなコンシューマの数などを確認する必要があります。また、メトリックスデータにより提供される平均値とピーク値を使用することもできます。
これらの基準になるメトリックスを設計時の期待値と比較することが重要です。それによって、クライアントコードが正常に動作していることを確認します。たとえば、コネクションが開いたままになっている、または、コンシュームされたメッセージが未通知のままになっているといった状態を確認できます。これらのコーディングエラーはメッセージサーバのリソースを消費し、パフォーマンスに大きな影響を及ぼします。
基準になる使用パターンは、最適なパフォーマンスを得るためにシステムを調整する方法を決定する上で役立ちます。たとえば、1 つの送信先がそのほかの送信先に比べ頻繁に使用されている場合は、その送信先のメッセージメモリー制限をそのほかの送信先より高く設定したり、使用率に応じて制限の動作を調整したりできます。必要なコネクション数が最大スレッドプールサイズによる許容値を大きく上回る場合は、スレッドプールサイズを増やすか、共有スレッドモデルを採用することができます。ピーク時のメッセージフローが平均フローより多い場合は、メモリーが不足したときに使用する制限の動作に影響することがあります。
一般に、使用パターンをより綿密に理解しているほど、より適切に、使用パターンに応じてシステムを調整し、将来ニーズに合わせてプランニングすることができます。
パフォーマンスに影響する要因メッセージの遅延とメッセージのスループットは、2 つの主要なパフォーマンスの評価基準です。これらは一般に、標準的なメッセージがメッセージ配信プロセスの各手順を完了するまでに要する時間に依存します。メッセージを持続的で信頼できる方法で配信する場合の各手順は次のとおりです。各手順を以下で図示します。
図 9-1 Message Queue サービスを使用したメッセージの配信
- メッセージはプロデューシングクライアントからメッセージサーバへ配信される
- メッセージサーバはメッセージの内容を読み取る
- メッセージは、信頼性を維持するために持続ストレージに配置される
- メッセージサーバは、信頼性を維持するためにメッセージの受信確認を発行する
- メッセージサーバは、メッセージのルーティングを決定する
- メッセージサーバはメッセージを書き込む
- メッセージはメッセージサーバからコンシューミングクライアントへ配信される
- コンシューミングクライアントは、信頼性を維持するためにメッセージの受信確認を発行する
- メッセージサーバは、信頼性を維持するために、クライアントの通知を処理する
- メッセージサーバは、クライアントの通知が処理されたことを通知する
これらの手順は順次実行されるため、プロデューシングクライアントからコンシューミングクライアントへメッセージを配信する際には、どの手順もボトルネックとなる恐れがあります。これらの手順の大半は、メッセージングシステムの物理的な特性に依存しています。物理的な特性には、ネットワーク帯域幅、コンピュータの処理速度、メッセージサーバのアーキテクチャなどが含まれます。ただし、一部の手順は、メッセージングアプリケーションの特性と必要とされる信頼性のレベルにも依存しています。
次の節では、アプリケーション設計の要因とメッセージングシステムの要因の両方がパフォーマンスに及ぼす影響について説明します。アプリケーション設計の要因とメッセージングシステムの要因はメッセージの配信に密接に関係しますが、各カテゴリは個別に考慮します。
パフォーマンスに影響するアプリケーション設計の要因
アプリケーション設計の決定は、メッセージングのパフォーマンス全体に大きく影響することがあります。
パフォーマンスに影響するもっとも重要な要因は、メッセージ配信の信頼性に影響を及ぼす要因です。次のような要因が含まれています。
そのほかに、パフォーマンスに影響するアプリケーション設計の要因には、次のものがあります。
以降の節では、これらの各要因がメッセージングパフォーマンスに及ぼす影響について説明します。原則として、パフォーマンスと信頼性は相反しています。つまり、信頼性が高くなるとパフォーマンスは低下します。
次の表は、さまざまなアプリケーション設計の要因が一般にどのようにメッセージングパフォーマンスに影響するかを示しています。表には、信頼性が高くパフォーマンスが低いシナリオと、パフォーマンスが高く信頼性の低いシナリオの 2 つのシナリオと、それぞれを特徴付ける主要なアプリケーション設計の要因を示します。これらの極端なシナリオの間には、信頼性とパフォーマンスの両方に影響する、多数の選択肢と兼ね合いがあります。
注
以下のグラフのパフォーマンスデータは、2 基の CPU を搭載した 1002 MHz の Solaris 8 システムでファイルベースの持続を使用して生成されたものです。パフォーマンステストでは、JIT コンパイラにより、システムを最適化し、持続データベースの準備をするために、最初に Message Queue ブローカを起動しました。
ブローカを起動した後、1 つのプロデューサと 1 つのコンシューマが作成され、メッセージが 30 秒間プロデュースされました。コンシューマがすべてのプロデュースされたメッセージを受信するために要した時間が記録され、スループットレート つまり 1 秒あたりのメッセージ数が計算されました。このシナリオは、表 9-1 に示すアプリケーション設計の要因の異なる組み合わせで繰り返し実行されました。
配信モード (持続的 / 持続性のないメッセージ)
「信頼性のあるメッセージング」で説明したとおり、持続性メッセージはメッセージサーバの障害時にもメッセージの配信を保証します。すべての対象のコンシューマが、メッセージをコンシュームしたことを通知するまで、ブローカはメッセージを持続ストアに格納します。
持続性メッセージのブローカの処理速度は、次の理由から、持続性のないメッセージの場合より低速です。
持続モードと非持続モードではパフォーマンスに大きな差が生じることがあります。図 9-2 は、信頼できる配信を行う 2 つのケースで、持続性メッセージと持続性のないメッセージのスループットを比較したものです。2 つのケースとは、永続的サブスクリプションを使用して 10K バイトのメッセージをキューに配信した場合とトピックに配信した場合です。どちらの場合も AUTO_ACKNOWLEDGE 通知モードを使用しています。
図 9-2 配信モードによるパフォーマンスへの影響
トランザクションの使用
トランザクションとは、処理済みセッションでプロデュースされたすべてのメッセージと処理済みセッションでコンシュームされたすべてのメッセージが、一体として処理されるか、または一体として処理されない、つまりロールバックされることを保証するものです。
Message Queue は、ローカルトランザクションと分散トランザクションの両方をサポートします (詳細は、それぞれ「ローカルトランザクション」と「分散トランザクション」を参照)。
処理済みセッションでのメッセージのプロデュースまたは通知の処理速度は、次の理由から、処理済みでないセッションの場合より低速です。
通知モード
JMS メッセージの配信の信頼性を保証する手段の 1 つは、Message Queue メッセージサーバによってクライアントへ配信されたメッセージのコンシュームをクライアントに通知するという方法です (「信頼性の高い配信 : 通知およびトランザクション」を参照)。
クライアントがメッセージを通知することなくセッションが閉じられた場合や、通知が処理される前にメッセージサーバに障害が生じた場合には、ブローカはメッセージを再配信して JMSRedelivered フラグをセットします。
処理済みでないセッションの場合、クライアントは、それぞれ固有のパフォーマンス特性をもつ 3 つの通知モードの中から 1 つを選択できます。
- AUTO_ACKNOWLEDGE コンシューマがメッセージを処理した後、システムは自動的にメッセージを通知する。このモードでは、プロバイダで障害が生じた後は、多くても 1 つのメッセージの再配信を保証するだけである
- CLIENT_ACKNOWLEDGE アプリケーションは、メッセージが通知されるポイントを制御する。直前の通知以降にそのセッションで処理されたすべてのメッセージが通知される。一連の通知の処理中にメッセージサーバに障害が生じた場合は、そのグループ内の複数のメッセージが再配信されることがある
- DUPS_OK_ACKNOWLEDGE このモードは、時間をかけてメッセージを通知するようにシステムに指示する。プロバイダに障害が生じた後でも、複数のメッセージを再配信できる。
CLIENT_ACKNOWLEDGE モードの使い方はトランザクションの使い方に似ています。ただし、処理中にプロバイダに障害が生じた場合に、すべての通知が一括して処理されることを保証していない点を除きます。
次の理由から、パフォーマンスは通知モードによる影響を受けます。
- AUTO_ACKNOWLEDGE モードと CLIENT_ACKNOWLEDGE モードでは、ブローカとクライアント間で特別な制御メッセージが必要である。追加の制御メッセージは、処理オーバーヘッドを高め、JMS ペイロードメッセージに干渉して処理遅延を引き起こすことがある
- AUTO_ACKNOWLEDGE モードと CLIENT_ACKNOWLEDGE モードでは、ブローカがクライアントの通知を処理したことを確認するまで、クライアントは待機する必要がある。その後、クライアントは追加メッセージをコンシュームできるようになる。このブローカの確認によって、何らかの理由でブローカがこれらのメッセージを再配信しないように保証する
- Message Queue 持続ストアは、コンシューマが受信したすべての持続性メッセージに関する通知情報を使って更新する必要がある。そのため、パフォーマンスは低下する
永続的サブスクリプションと永続的でないサブスクリプション
トピック送信先へのサブスクライバは、「パブリッシュ / サブスクライブ (トピック送信先)」で説明したとおり、永続的サブスクリプションをもつものと、永続的でないサブスクリプションをものものの 2 つのカテゴリに分かれます。
永続的サブスクリプションは、次の理由から、スループットを低下させる代わりに信頼性を向上させます。
- Message Queue メッセージサーバは、メッセージサーバに障害が生じた場合でも回復後にリストを使用できるように、各永続的サブスクリプションに割り当てられたメッセージのリストを持続的に格納する必要がある
- メッセージサーバに障害が生じた場合でも、回復後に、対応するコンシューマがアクティブになったときに、メッセージを引き続き配信できるように、永続的サブスクリプションの持続性メッセージは持続ストアに格納される。対照的に、永続的でないサブスクリプションの持続性メッセージは持続ストアには格納されない。したがって、メッセージサーバに障害が生じると、対応するコンシューマコネクションは失われ、メッセージは配信されない
図 9-3 は、10K バイトの、持続性メッセージと持続性のないメッセージの 2 とおりのケースで、永続的サブスクリプションと永続的でないサブスクリプションを使用したトピック送信先のスループットを比較したものです。どちらの場合も AUTO_ACKNOWLEDGE 通知モードを使用しています。
図 9-3 から、パフォーマンスへの影響が顕著となるのは、永続的サブスクリプションを使用した持続性メッセージの場合だけであることがわかります。上記のとおり、この場合の影響は、永続的サブスクリプションを使用したときに持続性メッセージだけが持続ストアに格納されることに起因しています。
図 9-3 サブスクリプションタイプによるパフォーマンスへの影響
セレクタの使用 (メッセージのフィルタリング)
アプリケーション開発者は、通常、特定のコンシューマへの一連のメッセージを対象にしています。それは、一意の送信先への一連のメッセージごとを対象とするか、単一の送信先を使用しコンシューマごとに複数のセレクタを登録することで実現できます。
セレクタとは文字列で、この文字列に一致するプロパティ値 (「JMS メッセージ構造」を参照) を持ったメッセージだけを特定のコンシューマに配信します。たとえば、セレクタ NumberOfOrders >1 は、NumberOfOrders プロパティ値が 2 以上のメッセージだけを配信します。
コンシューマにセレクタを登録すると、各メッセージを取り扱うために追加処理が必要となり、複数の送信先を使用する場合に比べ、パフォーマンスは低下します。以降のメッセージを比較する際にも構文解析できるセレクタを使用する必要があります。さらに、各メッセージがルートされるたびに、各メッセージのメセージプロパティを読み取り、比較する必要があります。ただし、セレクタを使用すると、メッセージングアプリケーションの柔軟性が向上します。
メッセージのサイズ
メッセージのサイズはパフォーマンスに影響します。プロデューシングクライアントからブローカへ、さらにブローカからコンシューミングクライアントへは、より多くのデータを渡す必要があり、持続性メッセージの場合はサイズの大きいメッセージを格納する必要があるからです。
ただし、複数のサイズの小さいメッセージを 1 つのメッセージにまとめることで、個々のメッセージの転送と処理を最小限に抑え、パフォーマンス全体を向上させることができます。この場合、個々のメッセージの状態に関する情報は失われてしまいます。
図 9-4 は、持続性メッセージと持続性のないメッセージの 2 とおりのケースで、1K、10K、および 100K バイトのメッセージのスループットを 1 秒あたりの K バイト数で比較したものです。どのケースも、メッセージはキュー送信先へ送信し、AUTO_ACKNOWLEDGE 通知モードを使用しています。
図 9-4 は、両方のケースで、小さいサイズのメッセージの場合に比べ、よりサイズの大きいメッセージを配信するほどオーバーヘッドが低くなることを示しています。また、1K バイトと 10K バイトのメッセージの場合は、持続性メッセージと持続性のないメッセージを比べたパフォーマンスの上昇は約 50% ですが、100K バイトのメッセージの場合、この差が維持されないことがわかります。おそらくこれは、100K バイトの場合には、ネットワークの帯域幅がメッセージスループットのボトルネックになるからでしょう。
図 9-4 メッセージのサイズによるパフォーマンスへの影響
メッセージ本体のタイプ
JMS がサポートするメッセージ本体のタイプ 5 種類の概要を複雑な順に次に示します。
一般に、メッセージのタイプはアプリケーションのニーズによって決定され、MapMessage や ObjectMessage などのより複雑なタイプほどパフォーマンスは低下します。データのシリアライズとデシリアライズがパフォーマンスを低下させます。パフォーマンスは、データがどの程度単純か、またはどの程度複雑かによって異なります。
パフォーマンスに影響するメッセージサービスの要因
メッセージングアプリケーションのパフォーマンスは、アプリケーション設計だけでなく、メッセージのルーティングと配信を実行するメッセージサービスによっても影響を受けます。
次の節では、パフォーマンスに影響することのあるさまざまなメッセージサービスの要因について説明します。これらの要因の影響を理解しておくことは、メッセージサービスの内容を変更したり、配置済みのアプリケーションで発生することのあるパフォーマンスボトルネックを診断し解決したりする上で重要となります。
Message Queue サービスのパフォーマンスに影響する最も重要な要因は、次のとおりです。
以降の節では、これらの各要因がメッセージングパフォーマンスに及ぼす影響について説明します。
ハードウェア
Message Queue メッセージサーバとクライアントアプリケーションのどちらの場合も、CPU の処理速度と使用可能なメモリーはメッセージサービスのパフォーマンスを決定する主要な要因となります。処理性能を強化して、多数のソフトウェア制限をなくす一方で、メモリーを追加して処理速度と能力を増加させることができます。ただし、一般に、単にハードウェアをアップグレードするだけでボトルネックを解消すると多額の費用がかかります。
オペレーティングシステム
同じハードウェアプラットフォームを前提とした場合でも、異なるオペレーティングシステムの効率によって、パフォーマンスも変わってきます。たとえば、オペレーティングシステムが採用しているスレッドモデルが、メッセージサーバがサポート可能な同時コネクション数に大きく影響することがあります。一般に、すべてのハードウェアが同じであれば、Solaris は通常 Linux より高速で、Linux は Windows より高速です。
Java 仮想マシン (JVM)
メッセージサーバは、ホスト JVM 内で実行され、ホスト JVM によってサポートされる Java プロセスです。そのため、JVM 処理は、メッセージサーバがメッセージをいかに早く効率良く転送し配信できるかを決定する重要な要因となります。
特に、JVM のメモリーリソースの管理が不可欠となる場合があります。増加し続けるメモリーの負荷に対応するには、JVM に十分なメモリーを割り当てる必要があります。さらに、JVM は定期的に未使用のメモリーを再利用します。このメモリー再利用がメッセージの処理を遅らせることがあります。JVM のメモリーヒープが大きくなるほど、メモリー再利用時に経験することのある潜在する遅延も長くなります。
コネクション
クライアントとブローカ間のコネクションの数と速度は、メッセージサーバが処理可能なメッセージ数とメッセージ配信速度に影響することがあります。
メッセージサーバのコネクションの制限
メッセージサーバへのアクセスはすべて、コネクション経由で行われます。同時コネクション数の制限によって、メッセージサーバが同時に使用できるプロデューシングクライアントまたはコンシューミングクライアントの数が左右されることがあります。
メッセージサーバへのコネクションの数は、一般に、使用可能なスレッド数によって制限されます。Message Queue は、スレッドプールマネージャを使用します。このマネージャは、専用スレッドモデルまたは共有スレッドモデルのどちらかを使用するように設定できます (「スレッドプールマネージャ」を参照)。専用スレッドモデルは、各コネクションが専用のスレッドを持つため非常に高速ですが、コネクションの数は使用可能なスレッド数によって制限されます。この場合、コネクションごとに、入力スレッドと出力スレッドが 1 つずつ必要です。共有スレッドモデルには、コネクション数の制限はありませんが、多数のコネクションでスレッドを共有するため、オーバーヘッドが増え、スループットが悪化します。これは、多くのコネクションが使用中のとき特に顕著になります。
トランスポートプロトコル
Message Queue ソフトウェアを使うと、クライアントは各種の低レベルのトランスポートプロトコルを使用してメッセージサーバと通信できます。Message Queue は、「コネクションサービスのサポート」に示すコネクションサービスとそれに対応するプロトコルをサポートします。暗号化、ファイアウォールを介したアクセスなどのプロトコルは、アプリケーション要件に基づいて選択されますが、選択結果はパフォーマンス全体に影響を及ぼします。
図 9-5 トランスポートプロトコルの速度
図 9-5 は、さまざまなプロトコルテクノロジのパフォーマンス特性を示しています。
図 9-6 は、2 つのケースでの TCP と SSL のスループットを比較したものである。2 つのケースとは、1K バイトの持続性メッセージを、永続的サブスクリプションと AUTO_ACKNOWLEDGE 通知モードを使用しているトピック送信先へ送信する高信頼性シナリオと、1K バイトの持続性のないメッセージを、永続的サブスクリプションと DUPS_OK_ACKNOWLEDGE 通知モードを使用しているトピック送信先へ送信するハイパフォーマンスシナリオである
図 9-6 は、高信頼性ケースの方がプロトコルによる影響は少ないことを示す。これは、高信頼性のケースで必要な持続性メッセージのためのオーバーヘッドの方が、プロトコルの速度より、スループットを制限する重要な要因となるからである
図 9-6 トランスポートプロトコルによるパフォーマンスへの影響
メッセージサービスのアーキテクチャ
Message Queue メッセージサーバは、シングルブローカ、または複数の連結されたブローカインスタンスであるブローカクラスタとして実装できます。
ブローカに接続するクライアントの数や配信されるメッセージの数が増えると、ブローカは最終的に、ファイル記述子、スレッド、メモリーの制限などのリソースの限界を超えてしまいます。増え続ける負荷に対処するための 1 つの方法は、Message Queue メッセージサーバにブローカインスタンスを追加して、クライアントのコネクションとメッセージのルーティングおよび配信を複数のブローカに分散することです。
一般に、ブローカインスタンスの追加は、クライアント、特にメッセージプロデューシングクライアントがクラスタ間で均等に分散されている場合に最適に動作します。クラスタ内のブローカ間でのメッセージ配信にはオーバーヘッドが伴うため、コネクション数とメッセージ配信レートが制限されているクラスタでは、シングルブローカよりパフォーマンスが低くなります。
また、ブローカクラスタを使用してネットワークの帯域幅を最適化することもできます。たとえば、クラスタ内の一連のリモートブローカ間で、速度の遅い、長距離のネットワークリンクを使用する一方で、個々のブローカインスタンスへのクライアントの接続に、高速なリンクを使用することができます。
クラスタの詳細については、「マルチブローカクラスタ (Enterprise Edition)」と「クラスタの操作 (Enterprise Edition)」を参照してください。
ブローカの制限と動作
メッセージを処理するためにメッセージサーバに要求されるメッセージスループットは、メッセージサーバがサポートするメッセージングアプリケーションの使用パターンによって異なります。ただし、メッセージサーバでは、メモリー、CPU サイクルなどのリソースに制限があります。リソースの制限により、メッセージサーバは、過負荷となり、無応答または不安定となるポイントに達してしまうことがあります。
Message Queue メッセージサーバには、メモリーリソースを管理し、ブローカのメモリー不足を防ぐためのメカニズムが組み込まれています。これらのメカニズムに含まれるのは、ブローカまたは個々の送信先が保持できるメッセージ数またはメッセージのバイト数についての設定可能な制限と、送信先の制限に達したときに起動できる一連の動作です (「メモリーリソースとメッセージフローの管理」を参照)。
これらの設定可能なメカニズムを使用して、システムが過負荷にならないように、メッセージの受信と送信のバランスを取ることができますが、これには注意深い監視と調整が必要です。これらのメカニズムは、オーバーヘッドを増加させ、メッセージのスループットを制限することがありますが、それでも動作の完全性を維持します。
データストアのパフォーマンス
Message Queue は、組み込み持続とプラグイン持続の両方をサポートしています ( 「持続マネージャ」を参照)。組み込み持続は、ファイルベースのデータストアです。プラグイン持続は、JDBC (Java Database Connectivity) インタフェースを使用し、JDBC 互換のデータストアを必要とします。
組み込み持続はプラグイン持続より高速です。一方、JDBC 互換のデータベースシステムではアプリケーションに必要な冗長性、セキュリティ、および管理機能を提供できます。
組み込み持続の場合は、持続的な操作によりメモリー内の状態とデータストアとを同期化するように指定することで、信頼性を高められます。この同期化は、システム破壊によるデータの損失をなくす上で役立ちますが、パフォーマンスが犠牲になります。
クライアントランタイムの設定
Message Queue クライアントランタイムは、クライアントアプリケーションに Message Queue メッセージサービスへのインタフェースを提供します。クライアントランタイムでは、送信先にメッセージを送信し、送信先からメッセージを受信する場合に、クライアントに必要なすべての処理をサポートします。クライアントランタイムは、コネクションファクトリ属性値を使って設定可能で、一般的にパフォーマンスとメッセージスループットを向上させるようにプロパティと動作を設定できます。
たとえば、Message Queue クライアントランタイムでは次の動作を設定できます。
- コネクションフロー測定 (imqConnectionFlowCount)。同じコネクションを経由する JMS メッセージと Message Queue 制御メッセージの両方に起因する輻輳を防ぐ上で役立つ
- コネクションフローの制限 (imqConnectionFlowLimit)。コンシュームされるのを待機するために、クライアントランタイムへのコネクションを介して配信可能なメッセージ数の制限により、クライアントリソースが制限されるのを回避する上で役立つ
- コンシューマフローの制限 (imqConsumerFlowLimit)。複数のコンシューマがキュー配信を実行する状況で、コンシューマが送信するメッセージの数が不均衡にならないように、コンシューマ間のロードバランスを改善する上で役立つ。また、コネクション上のあるコンシューマがそのコネクション上の別のコンシューマから過剰な負荷を受けないように防ぐ。このプロパティは、コンシュームされるのを待機するために、コンシューマがクライアントランタイムへのコネクションを介して配信できるコンシューマあたりのメッセージ数を制限する。また、このプロパティはキュー送信先プロパティとして設定することもできる (consumerFlowLimit)
これらの動作とそれを設定するために使用される属性の詳細は、「クライアントランタイムのメッセージフローの調整」を参照してください。
メッセージサーバの監視Message Queue サーバは、パフォーマンスの監視に使用可能なメトリックス情報を提供するように設定できます。この節では、メッセージサーバの監視に使用可能なさまざまなツールと、これらのツールを使用して取得できるメトリックスデータについて説明します。
メトリックスデータを使用して、パフォーマンス問題を解決する方法やメッセージサーバのパフォーマンスを分析し調整する方法については、「パフォーマンス問題のトラブルシューティング」を参照してください。
監視ツール
次のツールを使用してメトリックス情報を取得できます。
次の節では、これらの各ツールを使用してメトリックス情報を取得する方法を説明します。さまざまなツールの比較については、「適切な監視ツールの選択」を参照してください。
Message Queueコマンドユーティリティ (imqcmd)
コマンドユーティリティ (imqcmd) は、Message Queue の基本的なコマンド行管理ツールです。このツールを使用して、ブローカとブローカのコネクションサービス、およびアプリケーション固有のリソースである物理的な送信先、永続的サブスクリプション、トランザクションなどを管理できます。imqcmd コマンドについては、第 6 章「ブローカとアプリケーションの管理」で説明されています。
imqcmd コマンドの機能の 1 つは、ブローカ全体、個々のコネクションサービス、個々の送信先に関するメトリックス情報を取得できる機能です。メトリックスデータを取得するには、一般に、imqcmd の metrics サブコマンドを使用します。メトリックスデータは、指定した間隔で、または指定した回数だけ、コンソール画面に表示されます。
また、query サブコマンド (「imqcmd query」を参照) を使用して、より限定されたメトリックスデータのサブセットを取得することもできます。
imqcmd metrics
imqcmd metrics の構文とオプションを、それぞれ表 9-2 と表 9-3 に示します。
手順 : metrics サブコマンドを使用したメトリックスデータの表示
この節では、metrics サブコマンドを使用してメトリックス情報を報告するための手順を説明します。
metrics サブコマンドを使用するには
- メトリックス情報が必要なブローカを起動します。
「ブローカの起動」を参照してください。
メトリックスの出力 : imqcmd metrics
この節では、ブローカ全体、コネクションサービス、送信先のメトリックスに関する metrics サブコマンドの出力例を示します。
ブローカ全体のメトリックス ブローカとの間のメッセージとパケットのフローレートを 10 秒間隔で取得するには、metrics bkr サブコマンドを使用します。
このコマンドは、次のような出力を生成します (表 9-8 のデータの説明を参照)。
コネクションサービスのメトリックス jms コネクションサービスが処理したメッセージとパケットの累計を取得するには、metrics svc サブコマンドを使用します。
このコマンドは、次のような出力を生成します (表 9-9 のデータの説明を参照)。
-------------------------------------------------
Msgs Msg Bytes Pkts Pkt Bytes
In Out In Out In Out In Out
-------------------------------------------------
164 100 120704 73600 282 383 135967 102127
657 100 483552 73600 775 876 498815 149948
送信先メトリックス 送信先に関するメトリックス情報を表示するには、metrics dst サブコマンドを使用します。
このコマンドは、次のような出力を生成します (表 9-10 のデータの説明を参照)。
-----------------------------------------------------------------------------
Msgs Msg Bytes Msg Count Total Msg Bytes (k) Largest
In Out In Out Current Peak Avg Current Peak Avg Msg (k)
-----------------------------------------------------------------------------
200 200 147200 147200 0 200 0 0 143 71 0
300 200 220800 147200 100 200 10 71 143 64 0
300 300 220800 220800 0 200 0 0 143 59 0
送信先のコンシューマに関する情報を取得するには、metrics dst サブコマンドを使用します。
このコマンドは、次のような出力を生成します (表 9-10 のデータの説明を参照)。
---------------------------------------------------------------- --
Active Consumers Backup Consumers Msg Count
Current Peak Avg Current Peak Avg Current Peak A vg
---------------------------------------------------------------- --
1 1 0 0 0 0 944 1000 5 25
imqcmd query
imqcmd query の構文とオプションを、コマンドによって提供されるメトリックスデータの説明とともに表 9-4 に示します。
表 9-4 imqcmd query サブコマンドの構文
サブコマンドの構文
提供されるメトリックスデータ
query bkr
[-b hostName:port]
[-int interval]
[-msp numSamples]ブローカのメモリーと持続ストアに格納されている現在のメッセージ数とメッセージバイト数に関する情報 (「ブローカ情報の表示」を参照)
または
metrics svc -n serviceName
[-b hostName:port]
[-int interval]
[-msp numSamples]指定したコネクションサービスに現在割り当てられているスレッドの数とそのサービスのコネクション数に関する情報 (「コネクションサービス情報の表示」を参照)
または
metrics dst -t destType
-n destName
[-b hostName:port]
[-int interval]
[-msp numSamples]指定した送信先のメモリーと持続ストアに格納されている現在のプロデューサ数、アクティブコンシューマとバックアップコンシューマの数、メッセージ数とメッセージバイト数に関する情報 (「送信先情報の表示」を参照)
注
imqcmd query は限定されたメトリックスデータを提供するため、このツールは、「メトリックスデータの送信先」の節の表には記載されていません。
Message Queueブローカログファイル
Message Queue のロガーは、ブローカコード、デバッガ、およびメトリックスジェネレータによって生成された情報を取得し、 標準出力 (コンソール)、ログファイル、SolarisTM プラットフォーム、syslog デーモンプロセスなどの多数の出力チャネルに書き込みます。ロガーについては、「ロガー」で説明されています。
ロガーが収集する情報のタイプと、各出力チャネルに書き込む情報のタイプを指定できます。特に、メトリックス情報のログファイルへの書き込みを指定できます。
手順 : ブローカログファイルを使用したメトリックスデータの報告
この節では、ブローカログファイルを使用してメトリックス情報を報告するための手順を説明します。ロガーの設定方法については、「ログ作成」を参照してください。
ログファイルを使用してメトリックス情報を報告するには
メトリックスの出力 : ログファイル
次は、ログファイルに出力されたブローカメトリックスのサンプルを示しています (表 9-7 と表 9-8 のメトリックスデータの説明を参照)。
[21/Jul/2003:11:21:18 PDT]
Connections: 0 JVM Heap: 8323072 bytes (7226576 free) Threads: 0 (14-1010)
In: 0 msgs (0bytes) 0 pkts (0 bytes)
Out: 0 msgs (0bytes) 0 pkts (0 bytes)
Rate In:0 msgs/sec (0 bytes/sec) 0 pkts/sec (0 bytes/sec)
Rate Out:0 msgs/sec (0 bytes/sec) 0 pkts/sec (0 bytes/sec)
メッセージベースの監視 API
Message Queue には、ブローカがメトリックスデータを JMS メッセージへ書き込み、そのメッセージに含まれるメトリックス情報のタイプに応じて、そのメッセージを多数のメトリックストピック送信先のどれかに送信する際に使用できるメトリックス監視機能が用意されています。
メトリックストピックを送信先へサブスクライブし、これらの送信先のメッセージをコンシュームし、メッセージに含まれるメトリックス情報を処理するクライアントアプリケーションをプログラミングすることで、このメトリックス情報にアクセスできます。このスキーマの概略については、「メトリックスメッセージプロデューサ (Enterprise Edition)」で説明されています。
5 つのメトリックストピック送信先があります。それらの名前と、各送信先へ配信されるメトリックスメッセージのタイプを表 9-5 に示します。
表 9-5 メトリックスのトピック送信先
トピック名
メトリックスメッセージのタイプ
mq.metrics.broker
ブローカのメトリックス
mq.metrics.jvm
Java 仮想マシンのメトリックス
mq.metrics.destination_list
送信先とそれらのタイプのリスト
mq.metrics.destination.queue.
monitoredDestinationName指定した名前のキューの送信先メトリックス
mq.metrics.destination.topic.
monitoredDestinationName指定した名前のトピックの送信先メトリックス
手順 : メッセージベースの監視の設定
この節では、メッセージベースの監視機能を使用してメトリックス情報を収集するための手順を説明します。手順には、クライアント開発タスクと管理タスクの両方が含まれます。
メッセージベースの監視を設定するには
- メトリックス監視クライアントを作成します。
メトリックストピック送信先へサブスクライブし、メトリックスメッセージをコンシュームし、これらのメッセージからメトリックスデータを抽出するクライアントをプログラミングする手順については、『Message Queue Java Client Developer's Guide』を参照してください。
- config.properties ファイルにブローカプロパティ値を設定して、ブローカのメトリックスメッセージプロデューサを設定します。
- メトリックスメッセージのプロデュースを有効にする
imq.metrics.topic.enabled=true と設定する
デフォルト値は true
- メトリックスメッセージを生成する間隔を、秒単位で指定する
imq.metrics.topic.interval=interval と設定する
デフォルトは 60 秒
- メトリックスメッセージを持続的にするかどうか、つまり、ブローカ障害時にもそのまま保持するかどうかを指定する
imq.metrics.topic.persist を設定する
デフォルト値は false
- 各送信先で、メトリックスメッセージを削除するまでに保持しておく期間を指定する
Set imq.metrics.topic.timetolive
デフォルト値は 300 秒
- メトリックストピック送信先に必要なアクセス制御を設定します。
設定方法は次の、「セキュリティとアクセスで考慮すること」を参照してください。
- メトリックス監視クライアントを起動します。
コンシューマがメトリックストピックをサブスクライブすると、メトリックストピック送信先が自動的に作成されます。メトリックストピックが作成されると、ブローカのメトリックスメッセージプロデューサがメトリックスメッセージをメトリックストピックへ送信し始めます。
セキュリティとアクセスで考慮すること
メトリックストピック送信先へのアクセスを制限する理由は 2 つあります。
これらの点を考慮して、メトリックストピック送信先へのアクセスは制御することをお勧めします。
監視クライアントは、そのほかのクライアントと同じ認証制御と権限を前提にしています。ブローカへの接続が許可されるのは、Message Queue ユーザーリポジトリに登録されているユーザーだけです。
「ユーザーの承認 : アクセス制御プロパティファイル」に説明されているとおり、アクセス制御プロパティファイルを使用して特定のメトリックストピック送信先へのアクセスを制限することで、さらに保護を強化できます。
たとえば、accesscontrol.properties ファイル内の次のエントリは、user1 と user2 を除き、すべてのユーザーについて mq.metrics.broker メトリックストピックへのアクセスを拒否します。
次のエントリは、ユーザー user3 だけにトピック t1 の監視を許可します。
topic.mq.metrics.destination.topic.t1.consume.deny.user=*
topic.mq.metrics.destination.topic.t1.consume.allow.user=user3
メトリックスデータの機密性に応じて、暗号化されたコネクションを使用してメトリックス監視クライアントをブローカへ接続することもできます。暗号化されたコネクションの使用方法については、「暗号化 : SSL ベースのサービスとの連動 (Enterprise Edition)」を参照してください。
メトリックスの出力 : メトリックスメッセージ
メッセージベースの監視 API を使用して取得したメトリックスデータ出力は、プログラミングしたメトリックス監視クライアントによって異なります。出力されるデータは、ブローカ内のメトリックスジェネレータによって提供されるデータだけに限定されます。このデータの完全なリストは、「メトリックスデータの送信先」を参照してください。
適切な監視ツールの選択
前の節で取り上げた監視ツールにはそれぞれ長所と短所があります。
たとえば、imqcmd metrics コマンドを使用すると、必要なときにニーズにあったサンプル情報をすばやく作成できますが、履歴情報を確認したりプログラム上データを操作したりするのは難しくなります。
一方、ログファイルはメトリックスデータの長期間の記録を提供しますが、ログファイルの情報を解析して有意義な情報を取得するのが難しくなります。
メッセージベースの監視 API を使うと、必要な情報を容易に抽出し、それを処理して、プログラム上データを操作するか書式化して、グラフを提示したり警告を送信したりできます。ただし、データをキャプチャし分析するためのカスタムアプリケーションをプログラミングする必要があります。
さらに、これらの各ツールは、ブローカによって生成された比較的難解なメトリックス情報のサブセットを収集します。どの監視ツールがどのメトリックスデータを収集するかについては、「メトリックスデータの送信先」を参照してください。
表 9-6 は、それぞれの長所と短所を示すことで、さまざまなツールを比較しています。
表 9-6 メトリックス監視ツールの長所と短所
メトリックス
監視ツール長所
短所
imqcmd metrics
リモート監視
スポット検査に適している
報告間隔はコマンドのオプションで設定されるため、即座に変更可能
必要とする特定のデータを容易に選択できる
わかり易い表形式でデータを表示
シングルコマンドではすべてのデータを取得できない
データ分析のプログラム化が困難
履歴レコードを作成しない
履歴的な傾向を確認するのが困難
ログファイル
定期的なサンプリング
履歴レコードの作成
ブローカプロパティの設定が必要。有効にするにはブローカをシャットダウンし再起動する必要がある
ローカル監視だけ
読み取りや解析が非常に困難なデータ形式。解析ツールなし
報告間隔を即座に変更できない。すべてのメトリックスデータについて同じ
柔軟にデータを選択できない
ブローカメトリックスだけ。送信先とコネクションサービスのメトリックスは含まれていない
間隔が短過ぎるとパフォーマンスに影響する可能性がある
メッセージベースの監視 API
リモート監視
対象となる特定のデータを容易に選択できる
データを電子的に分析し、任意の形式で提示できる
ブローカプロパティの設定が必要。有効にするにはブローカをシャットダウンし再起動する必要がある
専用のメトリックス監視クライアントをプログラミングする必要がある
報告間隔を即座に変更できない。すべてのメトリックスデータについて同じ
メトリックスデータの送信先
ブローカによって報告されるメトリックス情報は、次のカテゴリにグループ化できます。
次の節では、これらの各カテゴリで使用可能なメトリックスデータについて取り上げます。次の表に記載されている監視ツールについては、「監視ツール」を参照してください。
JVM メトリックス
表 9-7 は、JVM ヒープを処理するためにブローカが生成するメトリックスとその説明、さらに各種監視ツールを使用してどのデータを取得できるかを一覧しています。
表 9-7 JVM メトリックス
メトリックス量
説明
imqcmd metrics bkr
(metricType)ログファイル
メトリックスメッセージ
(metrics topic)1JVM heap:
free memoryJVM ヒープに使用可能な空きメモリー量
必須
(cxn)必須
必須
(...jvm)JVM heap:
total memory現在の JVM ヒープサイズ
必須
(cxn)必須
必須
(...jvm)JVM heap:
max memoryJVM ヒープサイズを拡大可能な上限
オプション
必須2
必須
(...jvm)
1メトリックスのトピック送信先名については、表 9-5 を参照
2ブローカの起動時にだけ表示される
ブローカ全体のメトリックス
表 9-8 は、ブローカ全体のメトリックス情報についてブローカが報告するデータとその説明を一覧しています。また、各種メトリックス監視ツールを使用してどのデータを取得できるかも示しています。
表 9-8 ブローカ全体のメトリックス
メトリックス量
説明
imqcmd metrics bkr
(metricType)ログファイル
メトリックスメッセージ
(metrics topic)1コネクションデータ
Num connections
現在開いているブローカへのコネクションの数
必須
(cxn)必須
必須
(...broker)Num threads
現在使用中のスレッドの数
必須
(cxn)必須
オプション
Min threads
コネクションサービスで使用するために、スレッドプールに保持している作成済みのスレッド数
必須
(cxn)必須
オプション
Max threads
コネクションサービスが使用するために、スレッドプールに保持するスレッドの最大数。新しいスレッドは、それ以上追加されなくなる
必須
(cxn)必須
オプション
格納済みのメッセージデータ
Num messages
現在、ブローカメモリーと持続ストアに格納されている JMS メッセージの数
オプション
query bkr を使用オプション
必須
(...broker)Total message bytes
現在、ブローカメモリーと持続ストアに格納されている JMS メッセージバイトの数
オプション
query bkr を使用オプション
必須
(...broker)メッセージフローデータ
Num messages in
ブローカが最後に起動された以降にブローカが受信した JMS メッセージの数
必須
(ttl)必須
必須
(...broker)Message bytes in
ブローカが最後に起動された以降にブローカが受信した JMS メッセージのバイト数
必須
(ttl)必須
必須
(...broker)Num packets in
ブローカが最後に起動された以降にブローカが受信したパケットの数。JMS メッセージと制御メッセージの両方が含まれる
必須
(ttl)必須
必須
(...broker)Packet bytes in
ブローカが最後に起動された以降にブローカが受信したパケットのバイト数。JMS メッセージと制御メッセージの両方が含まれる
必須
(ttl)必須
必須
(...broker)Num messages out
ブローカが最後に起動された以降にブローカから送信した JMS メッセージの数
必須
(ttl)必須
必須
(...broker)Message bytes out
ブローカが最後に起動された以降にブローカから送信した JMS メッセージのバイト数
必須
(ttl)必須
必須
(...broker)Num packets out
ブローカが最後に起動された以降にブローカから送信したパケットの数。JMS メッセージと制御メッセージの両方が含まれる
必須
(ttl)必須
必須
(...broker)Packet bytes out
ブローカが最後に起動された以降にブローカから送信したパケットのバイト数。JMS メッセージと制御メッセージの両方が含まれる
必須
(ttl)必須
必須
(...broker)Rate messages in
ブローカへの JMS メッセージの現在のフローレート
必須
(rts)必須
オプション
Rate message bytes in
ブローカへの JMS メッセージバイトの現在のフローレート
必須
(rts)必須
オプション
Rate packets in
ブローカへのパケットの現在のフローレート。JMS メッセージと制御メッセージの両方を含む
必須
(rts)必須
オプション
Rate packet bytes in
ブローカへのパケットバイトの現在のフローレート。JMS メッセージと制御メッセージの両方を含む
必須
(rts)必須
オプション
Rate messages out
ブローカからの JMS メッセージの現在のフローレート
必須
(rts)必須
オプション
Rate message bytes out
ブローカからの JMS メッセージのバイトの現在のフローレート
必須
(rts)必須
オプション
Rate packets out
ブローカからのパケットの現在のフローレート。JMS メッセージと制御メッセージの両方を含む
必須
(rts)必須
オプション
Rate packet bytes out
ブローカからのパケットバイトの現在のフローレート。JMS メッセージと制御メッセージの両方を含む
必須
(rts)必須
オプション
送信先データ
Num destinations
ブローカ内の物理的な送信先の数
オプション
オプション
必須
(...broker)
コネクションサービスのメトリックス
表 9-9 は、個々のコネクションサービスについてブローカが報告するメトリックスデータとその説明を一覧しています。また、各種メトリックス監視ツールを使用してどのデータを取得できるかも示しています。
表 9-9 コネクションサービスのメトリックス
メトリックス量
説明
imqcmd metrics svc
(metricType)ログファイル
メトリックスメッセージ
(metrics topic)コネクションデータ
Num connections
現在開かれているコネクション数
必須
(cxn)
query svc も使用オプション
オプション
Num threads
すべてのコネクションサービスで、現在使用中のスレッドの合計数
必須
(cxn)
query svc も使用オプション
オプション
Min threads
すべてのコネクションサービスで、コネクションサービスが使用するスレッドプールに初めに保持されるスレッドの合計数
必須
(cxn)オプション
オプション
Max threads
すべてのコネクションサービスで、コネクションサービスが使用するスレッドプールに保持されるスレッドの最大合計数。新しいスレッドは、それ以上追加されなくなる
必須
(cxn)オプション
オプション
メッセージフローデータ
Num messages in
ブローカが最後に起動された以降にコネクションサービスが受信した JMS メッセージの数
必須
(ttl)オプション
オプション
Message bytes in
ブローカが最後に起動された以降にコネクションサービスが受信した JMS メッセージのバイト数
必須
(ttl)オプション
オプション
Num packets in
ブローカが最後に起動された以降にコネクションサービスが受信したパケットの数。JMS メッセージと制御メッセージの両方が含まれる
必須
(ttl)オプション
オプション
Packet bytes in
ブローカが最後に起動された以降にコネクションサービスが受信したパケットのバイト数。JMS メッセージと制御メッセージの両方が含まれる
必須
(ttl)オプション
オプション
Num messages out
ブローカが最後に起動された以降にコネクションサービスから送信した JMS メッセージの数
必須
(ttl)オプション
オプション
Message bytes out
ブローカが最後に起動された以降にコネクションサービスから送信した JMS メッセージのバイト数
必須
(ttl)オプション
オプション
Num packets out
ブローカが最後に起動された以降にコネクションサービスから送信したパケットの数。JMS メッセージと制御メッセージの両方が含まれる
必須
(ttl)オプション
オプション
Packet bytes out
ブローカが最後に起動された以降にコネクションサービスから送信したパケットのバイト数。JMS メッセージと制御メッセージの両方が含まれる
必須
(ttl)オプション
オプション
Rate messages in
コネクションサービス経由でブローカが受信する JMS メッセージの現在のフローレート
必須
(rts)オプション
オプション
Rate message bytes in
コネクションサービスへの JMS メッセージバイトの現在のフローレート
必須
(rts)オプション
オプション
Rate packets in
コネクションサービスへのパケットの現在のフローレート。JMS メッセージと制御メッセージの両方を含む
必須
(rts)オプション
オプション
Rate packet bytes in
コネクションサービスへのパケットの現在のフローレート。JMS メッセージと制御メッセージの両方を含む
必須
(rts)オプション
オプション
Rate messages out
コネクションサービスからの JMS メッセージの現在のフローレート
必須
(rts)オプション
オプション
Rate message bytes out
コネクションサービスからの JMS メッセージバイトの現在のフローレート
必須
(rts)オプション
オプション
Rate packets out
コネクションサービスからのパケットの現在のフローレート。JMS メッセージと制御メッセージの両方を含む
必須
(rts)オプション
オプション
Rate packet bytes out
コネクションサービスからのパケットバイトの現在のフローレート。JMS メッセージと制御メッセージの両方を含む
必須
(rts)オプション
オプション
送信先メトリックス
表 9-9 は、個々の送信先についてブローカが報告するメトリックスデータとその説明を一覧しています。また、各種メトリックス監視ツールを使用してどのデータを取得できるかも示しています。
表 9-10 送信先メトリックス
メトリックス量
説明
imqcmd metrics dst
(metricType)ログファイル
メトリックスメッセージ
(metrics topic)1コンシューマのデータ
Num active consumers
現在のアクティブなコンシューマの数
必須
(con)オプション
必須
(...destName)Avg num active consumers
ブローカが最後に起動された以降のアクティブなコンシューマの数の平均
必須
(con)オプション
必須
(...destName)Peak num active consumers
ブローカが最後に起動された以降のアクティブなコンシューマの最大時の数
必須
(con)オプション
必須
(...destName)Num backup consumers
現在のバックアップコンシューマの数。キューにだけ適用
必須
(con)オプション
必須
(...destName)Avg num backup consumers
ブローカが最後に起動された以降のバックアップコンシューマ数の平均。キューにだけ適用
必須
(con)オプション
必須
(...destName)Peak num backup consumers
ブローカが最後に起動された以降のバックアップコンシューマの最大時の数。キューにだけ適用
必須
(con)オプション
必須
(...destName)格納済みのメッセージデータ
Num messages
現在、送信先メモリーと持続ストアに格納されている JMS メッセージの数
必須
(con)
(ttl)
(rts)
query dst も使用オプション
必須
(...destName)Avg num messages
ブローカが最後に起動された以降に、送信先メモリーと持続ストアに格納された JMS メッセージ数の平均
必須
(con)
(ttl)
(rts)オプション
必須
(...destName)Peak num messages
ブローカが最後に起動された以降に、送信先メモリーと持続ストアに格納された JMS メッセージの最大時の数
必須
(con)
(ttl)
(rts)オプション
必須
(...destName)Total message bytes
現在、送信先メモリーと持続ストアに格納されている JMS メッセージのバイト数
必須
(ttl)
(rts)
query dst も使用オプション
必須
(...destName)Avg total message bytes
ブローカが最後に起動された以降に、送信先メモリーと持続ストアに格納された JMS メッセージのバイト数の平均
必須
(ttl)
(rts)オプション
必須
(...destName)Peak total message bytes
ブローカが最後に起動された以降に、送信先メモリーと持続ストアに格納された JMS メッセージの最大時のバイト数
必須
(ttl)
(rts)オプション
必須
(...destName)Peak message bytes
ブローカが最後に起動された以降に、送信先が受信したシングルメッセージ内の JMS メッセージの最大時のバイト数
必須
(ttl)
(rts)オプション
必須
(...destName)メッセージフローデータ
Num messages in
ブローカが最後に起動された以降に、この送信先が受信した JMS メッセージの数
必須
(ttl)オプション
必須
(...destName)Msg bytes in
ブローカが最後に起動された以降に、この送信先が受信した JMS メッセージのバイト数
必須
(ttl)オプション
必須
(...destName)Num messages out
ブローカが最後に起動された以降に、この送信先から送信した JMS メッセージの数
必須
(ttl)オプション
必須
(...destName)Msg bytes out
ブローカが最後に起動された以降に、この送信先から送信した JMS メッセージのバイト数
必須
(ttl)オプション
必須
(...destName)Rate num messages in
送信先への JMS メッセージの現在のフローレート
必須
(rts)オプション
オプション
Rate num messages out
送信先からの JMS メッセージの現在のフローレート
必須
(rts)オプション
オプション
Rate msg bytes
in送信先への JMS メッセージバイトの現在のフローレート
必須
(rts)オプション
オプション
Rate Msg bytes
out送信先からの JMS メッセージのバイトの現在のフローレート
必須
(rts)オプション
オプション
ディスク利用率データ
Disk reserved
メッセージレコードが使用する、送信先のファイルベースのストアにある、アクティブレコードと空きレコードを含むすべてのメッセージレコードによって使用されているディスクスペース (バイト単位)
必須
(dsk)オプション
必須
(...destName)Disk used
送信先のファイルベースのストアにあるアクティブメッセージレコードによって使用されているディスクスペース (バイト単位)
必須
(dsk)オプション
必須
(...destName)Disk utilization ratio
使用されているディスクスペースを予約済みのディスクスペースで割ったときの商。割合が高いほど、アクティブメッセージを保持するためにより多くのディスクスペースが使用されている
必須
(dsk)オプション
必須
(...destName)
パフォーマンス問題のトラブルシューティングMessage Queue サービスを使用してアプリケーションをサポートする際に発生する恐れのある多数のパフォーマンス問題があります。このような問題には次のものが含まれます。
各問題を取り上げ、その考えられる原因と解決方法を説明します。
問題 : クライアントがコネクションを確立できない
現象 :
考えられる原因 :
この問題の原因を確認するには
すべてのコネクションサービスのステータスを確認します。
コネクションサービスのステータスが unknown または paused と表示された場合、クライアントはそのサービスを使用するコネクションを確立できません。
問題を解決するには
SSL サービスを適切に設定する方法については、「TCP/IP を介した SSL ベースのサービスの設定」を参照してください。
- コネクションサービスのステータスが paused と表示された場合は、サービスを再開します (「コネクションサービスの停止および再開」を参照)。
この問題の原因を確認するには
ブローカログの次のエントリを確認します。WARNING [B3004]: No threads are available to process a new connection on service ... Closing the new connection.
また、コネクションサービスのコネクション数と現在使用中のスレッド数を確認します。
コネクションごとに 2 つのスレッドが必要です。1 つは受信メッセージ用、もう 1 つは出力メッセージ用です (「スレッドプールマネージャ」を参照)。
問題を解決するには
- 専用のスレッドプールモデル (imq.service_name. threadpool_model=dedicated) を使用している場合は、コネクションの最大数はスレッドプールにあるスレッドの最大数の半分です。そのため、コネクション数を増やすには、スレッドプールのサイズを拡大するか (imq.service_name.max_threads)、共有スレッドプールモデルに切り換えます。
- 共有スレッドプールモデル (imq.service_name. threadpool_model=shared) を使用している場合は、コネクションの最大数は次の 2 つのプロパティの結果の半分です。それは、コネクション監視制限 (imq.service_name.connectionMonitor_limit) とスレッドの最大数 (imq.service_name.max_threads) です。そのため、コネクション数を増やすには、スレッドプールのサイズを拡大するか、コネクション監視制限の値を大きくします。
- 最終的に、サポート可能なコネクションの数またはコネクションのスループットが入力 / 出力制限に達してしまいます。このような場合は、マルチブローカクラスタ (「クラスタの操作 (Enterprise Edition)」を参照) を使用して、クラスタ内のブローカインスタンス間でコネクションを分散します。
- Solaris または Linux プラットフォーム上で必要なコネクション数に対してファイル記述子が少な過ぎる (「OS で定義されるファイル記述子の制限事項」を参照)
TCP バックログが、同時コネクション要求の数を制限する。ポートマッパーが追加要求を拒否しなければ、同時コネクション要求はシステムバックログ (imq.portmapper.backlog) に格納される。Windows プラットフォームでは、バックログ制限は固定されていて、 Windows クライアントでは 5、Windows サーバでは 200 に制限されている
通常、バックログ制限が原因の要求拒否は過渡的な現象であり、非常に多数の同時コネクション要求があると発生する
この問題の原因を確認するには
ブローカログで、一部のコネクション要求は受け入れられたが、ほぼ同時に受け取ったほかのコネクション要求が拒否されていないかどうかを確認します。拒否されたコネクション要求は、java.net.ConnectException: Connection refused を返します。
問題を解決するには
次の手順で、TCP バックログ制限を解消できます。
不正なパスワード、ユーザーリポジトリにユーザーのエントリがない、またはユーザーがコネクションサービスへのアクセス許可を持っていないといった原因で、認証は失敗することがあります。
この問題の原因を確認するには
ブローカログのエントリで Forbidden エラーメッセージを確認します。このメッセージは、認証エラーを示しているだけで、その理由は示していません。
問題を解決するには
- ユーザーリポジトリにユーザーのエントリがない場合は、ユーザーリポジトリにユーザーを追加します (「ユーザーリポジトリの設定と管理」を参照)。
- 不正がパスワードが使用された場合は、正しいパスワードを入力し直します。
- アクセス制御プロパティが不正に設定されていた場合は、アクセス制御プロパティファイルを編集し、コネクションサービスへのアクセス許可を与えます (「コネクションアクセス制御」を参照)。
問題 : コネクションスループットが遅過ぎる
現象 :
- メッセージスループットが期待どおりでない
- サポートされるブローカへのコネクション数は、「問題 : クライアントがコネクションを確立できない」で説明したように制限されているわけではなく、メッセージの入力 / 出力レートによって制限されている
考えられる原因 :
- コネクションサービスプロトコルは、TCP に比べ、本質的に低速です。たとえば、SSL ベースのプロトコルや HTTP ベースのプロトコルは、TCP より低速です (図 9-5を参照)。
この問題の原因を確認するには
SSL ベースのプロトコルまたは HTTP ベースのプロトコルを使用している場合は、TCP を使用して配信時間を比較してみます。
問題を解決するには
通常、アプリケーション要件によって使用するプロトコルが決定されます。そのため、「トランスポートプロトコルの調整」の説明にしたがいプロトコルを調整する以外に、対象方法はほとんどありません。
この問題の原因を確認するには
プロトコルを調整し、違いが生じるかどうかを確認します。
問題を解決するには
「トランスポートプロトコルの調整」の説明にしたがいプロトコルを調整します。
この問題の原因を確認するには
コネクションスループットが低速であるように見えるが、前に述べたような原因が見当たらない場合は、図 9-1 を参照して、そのほかの考えられるボトルネックを特定し、次の問題に関連する現象が出ていないかどうかを確認します。
問題を解決するには
前に述べた問題のトラブルシューティングの節に記載された問題の解決方法に従います。
問題 : クライアントがメッセージプロデューサを作成できない
現象 :
考えられる原因 :
送信先でのメッセージの蓄積を回避する 1 つの方法は、送信先がサポート可能なプロデューサの数を (maxNumProducers) で限定することです。
この問題の原因を確認するには
送信先を確認します (「送信先情報の表示」を参照)。
出力に現在のプロデューサ数と maxNumProducers の値が表示されます。2 つの値が同じ場合、プロデューサ数は設定済みの制限に達しています。ブローカは新しいプロデューサを拒否したときには、ResourceAllocationException [C4088]: A JMS destination limit was reached を返し、ブローカログに次のエントリを作成します。[B4183]: Producer can not be added to destination.
問題を解決するには
maxNumProducers 属性の値を大きくします (「送信先の属性の更新」を参照)。
この問題の原因を確認するには
ブローカは新しいプロデューサを拒否したときには、JMSSecurityException [C4076]: Client does not have permission to create producer on destination を返し、ブローカログに次のエントリを作成します。[B2041]: Producer on destination denied および [B4051]: Forbidden guest
問題を解決するには
ユーザーがメッセージをプロデュースできるようにアクセス制御プロパティを変更します (「送信先アクセス制御」を参照)。
問題 : メッセージのプロデュースが遅れるまたは低速である
現象 :
考えられる原因 :
送信先メモリー内のメッセージ数またはメッセージのバイト数が設定された制限に達すると、ブローカは指定された制限の動作に従いメモリーリソースを節約しようとします。次の制限の動作により、メッセージプロデューサの処理速度が低下します。
同様に、ブローカ全体のメモリー内 (すべての送信先に対応) のメッセージ数またはメッセージのバイト数が設定済みの制限に達すると、ブローカは最新のメッセージを拒否してメモリーリソースを節約しようとします。
また、送信先またはブローカ全体の制限が適切に設定されていないために、システムメモリーの制限に達すると、ブローカはメッセージプロデューサを徐々に減らすなどのさらに重大なアクションを実行してメモリーの過負荷を防ぎます。
これらのメカニズムについては、「メモリーリソースとメッセージフローの管理」を参照してください。
この問題の原因を確認するには
設定済みのメッセージの制限が原因でブローカによってメッセージが拒否された場合は、ブローカが JMSException [C4036]: A server error occurred を返し、ブローカログに次のエントリを作成します。WARNING [B2011]: Storing of JMS message from IMQconn failed に続き、制限に達したことを示すメッセージが表示されます。
多くの場合は、送信先とブローカにクエリーし設定済みのメッセージ制限の設定値を検査するか、送信先またはブローカ全体の現在のメッセージ数とメッセージのバイト数を監視し適切な imqcmd コマンドを使用することで、拒否される前にメッセージの制限条件を確認できます (それぞれ、表 9-10 と表 9-8 を参照)。
問題を解決するには
メッセージがバックログされたことでプロデューサの処理が低下する問題を解消するためのアプローチは多数あります。
ブローカがデータストアにアクセスできないか、または持続性メッセージをデータストアに書き込めない場合は、プロデューシングクライアントがブロックされます。前に述べたとおり、この状態は、送信先またはブローカ全体のメッセージ制限に達したときにも発生します。
この問題の原因を確認するには
ブローカは、データストアに書き込めない場合には、ブローカログに次のエントリのどれかを作成します。[B2011]: Storing of JMS message from connectionID failed... または [B4004]: Failed to persist message messageID...
問題を解決するには
- 組み込み持続の場合は、ファイルベースのデータストアのディスクスペースを増やしてみる
- JDBC 互換のデータストアの場合は、プラグイン持続が正しく設定されていることを確認する (付録 B 「プラグイン持続の設定」を参照)。正しく設定されている場合は、データベース管理者にほかのデータベース問題の解決を依頼する
低速なコネクションまたは、CPU 使用率が高いかメモリーリソースが不十分なためにメッセージサーバの能力が低下したことが原因で、ブローカが持続性メッセージの受信を通知するまでに、コネクションファクトリの imqAckTimeout 属性値で許容されている以上の時間を必要としています。
この問題の原因を確認するには
imqAckTimeout 値を超えると、ブローカは JMSException [C4000]: Packet acknowledge failed. を返します。
問題を解決するには
imqAckTimeout コネクションファクトリ属性値を変更します (「コネクションファクトリ管理対象オブジェクトの属性」を参照)。
この問題の原因を確認するには
問題を解決するには
JVM を調整します (「Java 仮想マシン (JVM) の調整」を参照)。
問題 : メッセージサーバでメッセージがバックログされる
現象 :
考えられる原因 :
メッセージは、すべてのコンシューマによってメッセージの送信先へ通知されるまで、送信先で保持されます。したがって、クライアントがコンシュームしたメッセージを通知しない場合、メッセージは削除されずに送信先で蓄積されます。
たとえば、クライアントコードは次の欠陥を持っている可能性があります。
この問題の原因を確認するには
メッセージサーバの負荷が高くない場合、つまり、送信先との間のメッセージのフローレートが低い場合は、通知されていないため、メッセージが蓄積されている可能性があります。
ブローカとの間のメッセージのフローレートを確認します。
その後、個々の送信先についてそれぞれのフローレートを確認します。
また、メッセージが正しく通知されているかどうかを判断するため、クライアントコードを確認します。
永続的サブスクリプションが非アクティブな場合は、該当するコンシューマがアクティブになりメッセージをコンシュームできるようになるまで、メッセージは送信先に格納されます。
この問題の原因を確認するには
各トピック送信先の永続的サブスクリプションの状態を確認します。
問題を解決するには
次のアクションのどれかを実行できます。
- 原因となっている永続的サブスクリプションのすべてのメッセージをパージする (「永続サブスクリプションの管理」を参照)
- トピックのメッセージの制限と制限の動作属性を指定する (表 6-10 を参照)。たとえば、メモリーに累積されたメッセージを削除する REMOVE_OLDEST および REMOVE_LOW_PRIORITY といった制限の動作を指定できる
- 該当する送信先からすべてのメッセージをパージする (「送信先のパージ」を参照)
- メッセージをメモリー内で存続できる時間を制限する。プロデューシングクライアントをプログラムし直し、メッセージごとに生存時間の値を設定できる。imqOverrideJMSExpiration および imqJMSExpiration コネクションファクトリ属性を設定することで、コネクションを共有するすべてのプロデューサのこれらの設定値をオーバーライドできる (表 7-3 を参照)
メッセージを配信可能なアクティブなコンシューマが少な過ぎる場合は、メッセージが蓄積するにつれ、キュー送信先がバックログされる恐れあります。この状態は、次の理由のどれかが原因で発生することがあります。
この問題の原因を確認するには
コンシューマ使用できない理由を判断するために、送信先のアクティブなコンシューマの数を確認します。
問題を解決するには
コンシューマが使用できない理由に応じて、次のアクションのどれかを実行できます。
- 追加のコンシューミングクライアントを起動して、キューに対応するアクティブなコンシューマを増やす
- imq.consumerFlowLimit ブローカプロパティを調整して、複数のコンシューマへのキュー配信を最適化する (「複数のコンシューマキューのパフォーマンス」を参照)
- キューのメッセージの制限と制限の動作属性を指定する (表 6-10 を参照)。たとえば、メモリーに累積されたメッセージを削除する REMOVE_OLDEST および REMOVE_LOW_PRIORITY といった制限の動作を指定できる
- 該当する送信先からすべてのメッセージをパージする (「送信先のパージ」を参照)
- メッセージをメモリー内で存続できる時間を制限する。プロデューシングクライアントをプラグらミングし直し、メッセージごとに生存期間の値を設定できる。imqOverrideJMSExpiration および imqJMSExpiration コネクションファクトリ属性を設定することで、コネクションを共有するすべてのプロデューサのこれらの設定値をオーバーライドできる (表 7-3 を参照)
この場合、トピックのサブスクライバまたはキューの受信側は、プロデューサがメッセージを送信する速度より遅い速度でメッセージをコンシュームしています。この不均衡が原因で、複数の送信先にメッセージがバックログされています。
この問題の原因を確認するには
ブローカとの間のメッセージのフローレートを確認します。
その後、個々の送信先についてそれぞれのフローレートを確認します。
問題を解決するには
- コンシューミングクライアントコードを最適化する
- キュー送信先の場合は、アクティブなコンシューマの数を増やす (「複数のコンシューマキューのパフォーマンス」を参照)
クライアントの通知処理には 2 つの要因が影響しています。
この問題の原因を確認するには
メッセージのフローをパケットのフローと比較して確認します。1秒当たりのパケット数がメッセージの数と比例していない場合は、クライアントの通知が問題と考えられます。
また、クライアントが JMSException [C4000]: Packet acknowledge failed メッセージを受信したかどうかを確認します。
問題を解決するには
- クライアントの通知モードを変更する。たとえば、DUPS_OK_ACKNOWLEDGEMENT または CLIENT_ACKNOWLEDGEMENT に切り換える
- CLIENT_ACKNOWLEDGEMENT または処理済みのセッションを使用している場合は、より多数のメッセージを単一の通知にグループ化する
- コンシューマとコネクションのフロー制御パラメータを調整する (「クライアントランタイムのメッセージフローの調整」を参照)
問題: メッセージサーバのスループットが散発的である
現象 :
考えられる原因 :
送信先とブローカに制限が適切に設定されなかったため、ブローカはメモリーが過負荷になるのを防ぐためにさらに重大なアクションを実行します。このため、メッセージのバックログがクリアされるまでは、ブローカの処理がかなり遅くなります。
この問題の原因を確認するには
ブローカのログで、メモリー不足の状態になっていないかどうかを確認します。[B1089]: In low memory condition, broker is attempting to free up resources に続き、メモリーの最新の状態と、使用中のメモリーの合計を示すエントリが表示されます。
また、JVM ヒープ内の使用可能な空きメモリーも確認します。
JVM メモリーの合計値が JVM メモリーの最大値に近くなると、空きメモリーは不足がちになります。
問題を解決するには
- JVM を調整する (「Java 仮想マシン (JVM) の調整」を参照)
- システムスワップスペースを増やす
定期的なメモリー再利用によりシステム全体を一掃し、メモリーを開放します。これが実行されると、すべてのスレッドがブロックされます。より多くのメモリーが開放され、JVM ヒープサイズがより大きくなるほど、メモリー再利用に起因する遅延も長くなります。
この問題の原因を確認するには
コンピュータ上の CPU 使用率を監視します。メモリー再利用が実行されると、大幅に低下します。
また、次のコマンド行オプションを使用してブローカを起動します。
標準出力では、メモリー再利用に要した時間が示されます。
問題を解決するには
複数の CPU を持つコンピュータでは、メモリー再利用を並行して実行するように設定します。
問題 : メッセージがコンシューマに到達しない
現象 :
考えられる原因 :
送信先メモリー内のメッセージ数またはメッセージのバイト数が設定済みの制限に達すると、ブローカはメモリーリソースを節約しようとします。これらの制限に達したときにブローカが実行する 3 つの設定可能な動作によって、メッセージが失われることがあります。
ブローカのメモリー内のメッセージ数またはメッセージのバイト数が設定済みの制限に達すると、ブローカは最新のメッセージを拒否してメモリーリソースを節約しようとします。
この問題の原因を確認するには
ブローカログで次のエントリを確認します。WARNING [B2011]: Storing of JMS message from...failed. このエントリには、制限を越えたことを示す別のエントリが続きます。エントリがない場合でも、メッセージが削除されたことが示されています。
問題を解決するには
制限を変更するか、動作を変更します。
時計が同期化されていない場合、ブローカによるメッセージの生存期間の計算がエラーとなり、メッセージが有効期限を越え、削除される場合があります。
この問題の原因を確認するには
すべてのコンピュータの時計を確認します。
問題を解決するには
時計を同期化します (「システムの時計の設定」を参照)。
パフォーマンスを改善するための設定の調整システムの調整
次の節では、オペレーティングシステム、JVM、および通信プロトコルで実行できる調整について説明します。
Solaris での調整 : CPU 使用率、ページング / スワッピング / ディスク I/O
オペレーティングシステムの調整については、システムのマニュアルを参照してください。
Java 仮想マシン (JVM) の調整
デフォルトでは、ブローカは 192M バイトの JVM ヒープサイズを使用します。通常、大量のメッセージ負荷がある場合はこのサイズでは小さ過ぎるため、大きくする必要があります。
Java オブジェクトが使用する JVM のヒープ容量を使い果たしそうになると、ブローカは、フロー制御やメッセージスワップなどのさまざまな技術を使用して、メモリーを解放します。極端な状況のもとでは、メモリーを開放し、メッセージの流入を減少させるために、クライアントコネクションを閉じることもあります。このような状況を避けるため、最大 JVM ヒープ容量を十分に高く設定するようお勧めします。
ただし、Java の最大ヒープ容量がシステムの物理メモリーに対して高くしすぎた場合、ブローカは Java ヒープ容量を増加し続け、システム全体のメモリーを使い果たしてしまうことがあります。これは、パフォーマンスの低下、予期しないブローカのクラッシュにつながり、そのシステムで実行されているほかのアプリケーションやサービスの動作にも影響を与える場合があります。一般に、オペレーティングシステムとそのほかのアプリケーションがマシンをマシン上で実行させるために十分な物理メモリーを使用させる必要があります。
一般に、通常時とピーク時のシステムメモリーフットプリントを評価して、十分なパフォーマンスを得られて、しかもシステムメモリーに問題を生じさせるほどではない大きさに Java ヒープサイズを設定するのがよい方法です。
ブローカの最小ヒープサイズと最大ヒープサイズを変更するには、ブローカの起動時に -vmargs コマンド行オプションを使用します。たとえば、次のように指定します。
このコマンドは、起動時の Java ヒープサイズを 256M バイトに、最大 Java ヒープサイズを 1G バイトに設定します。
- Solaris では、/etc/rc、つまり /etc/init.d/imq を介してブローカを起動する場合には、/etc/imq/imqbrokerd.conf ファイルにブローカコマンド行引数を指定する。詳細は、そのファイルのコメントを参照
- Windows では、ブローカを Windows のサービスとして起動する場合には、imqsvcadmin install コマンドに -vmargs オプションを使用して JVM 引数を指定する「サービス管理ユーティリティ (imqsvcadmin)」を参照
どの場合も、ブローカのログファイルを確認するか、imqcmd metrics bkr -m cxn コマンドを使用して、設定を検証します。
トランスポートプロトコルの調整
アプリケーションのニーズを満たすプロトコルが選択されたら、選択されたプロトコルに基づいて調整を加えることでパフォーマンスを改善できます。
プロトコルのパフォーマンスは、次の 3 つのブローカプロパティを使用して修正できます。
TCP と SSL プロトコルの場合、これらのプロパティがクライアントとブローカ間のメッセージ配信の速度に影響します。HTTP プロトコルと HTTPS プロトコルの場合は、これらのプロパティが、Web サーバ上で実行している Message Queue トンネルサーブレットとブローカ間のメッセージ配信の速度に影響します。HTTP/HTTPS プロトコルの場合、そのほかにもパフォーマンスに影響することのあるプロパティがあります (「HTTP/HTTPS の調整」を参照)。
プロトコルを調整するためのプロパティについては、次の節で説明します。
nodelay
nodelay プロパティは、特定のプロトコルの Nagle のアルゴリズム、つまり TCP/IP 上の TCP_NODELAY ソケットレベルのオプションの値に影響します。Nagle のアルゴリズムは、広域ネットワーク (WAN) などの低速コネクションを使用しているシステム上で TCP パフォーマンスを改善するために使用されます。
このアルゴリズムが使用されている場合、TCP は、データをサイズの大きいパケットにバンドルすることで、複数の小さいデータの塊がリモートシステムへ送信されるのを防ぎます。ソケットに書き込まれたデータが必要なバッファサイズを満たしていない場合、プロトコルは、バッファが満たされるか、一定の遅延時間が経過するまで、パケットの送信を遅らせます。バッファがいっぱいになるか、タイムアウトが発生すると、パケットが送信されます。
大半のメッセージングアプリケーションでは、パケットの送信に遅延がない、つまりNagle のアルゴリズムが無効な場合にパフォーマンスは最適となります。これは、クライアントとブローカ間の大半の対話が、要求 / 応答型の対話だからです。つまり、クライアントはデータのパケットをブローカへ送信し、その応答を待ちます。たとえば、典型的な対話には次のものがあります。
これらの対話では、大半のパケットがバッファサイズより小さいサイズです。つまり、Nagle のアルゴリズムが使用されている場合は、ブローカは数ミリ秒遅れて、コンシューマに応答を送信します。
ただし、Nalge のアルゴリズムは、コネクションが低速でブローカの応答が必要ない状況で、パフォーマンスを改善することができます。これは、クライアントが持続性のないメッセージを送信する場合や、クライアント通知がブローカによって確認されない場合 (DUPS_OK_ACKNOWLEDGE セッション) です。
inbufsz/outbufsz
inbufsz プロパティは、ソケットからのデータを読み取る入力ストリームのバッファサイズを設定します。同様に、outbufsz は、ブローカがデータをソケットに書き込むために使用する出力ストリームのバッファサイズを設定します。
一般に、どちらのパラメータも受信パケットまたは送信パケットの平均サイズより多少大きい値に設定する必要があります。経験上、これらのプロパティはパケットの平均サイズに 1K バイトを足した値 (K バイト単位で四捨五入) に設定すると良いでしょう。
たとえば、本体が 1K バイトのパケットをブローカで受信している場合、パケット全体のサイズ (メッセージ本体 + ヘッダー + プロパティ) は約 1200 バイトです。inbufsz を 2K バイト (2048 バイト) にすると、妥当なパフォーマンスが得られます。
inbufsz または outbufsz をそのサイズより大きくすると多少パフォーマンスは改善しますが、コネクションごとに必要なメモリーも増えます。
図 9-6 は、1K バイトのパケットの inbufsz を変更した結果を示しています。
図 9-7 1K バイト (1024 バイト) パケットの inbufsz を変更した結果
図 9-8 は、1K バイトのパケットの outbufsz を変更した結果を示しています。
図 9-8 1K バイト (1024 バイト) パケットの outbufsz を変更した結果
HTTP/HTTPS の調整
前の 2 つの節で説明した一般的なプロパティに加え、HTTP/HTTPS のパフォーマンスは、Message Queue トンネルサーブレットをホスティングする Web サーバへの HTTP 要求をクライアントが作成する速度によっても制限されます。
Web サーバは、シングルソケットで複数の要求を処理するように最適化する必要があります。JDK バージョン 1.4 以降では、Web サーバが複数の HTTP 要求を処理する際に使用するリソースを最小限にするために、Web サーバへの HTTP コネクション (Web サーバへのソケット) は開かれたままになっています。JDK 1.4 を使用しているクライアントアプリケーションのパフォーマンスが JDK の旧リリースで稼働している同じアプリケーションより低速な場合は、パフォーマンスを改善するために Web サーバのキープアライブ設定パラメータの調整が必要となることがあります。
このような Web サーバの調整に加え、クライアントが Web サーバをポーリングする頻度を調整することもできます。HTTP は要求ベースのプロトコルです。つまり、HTTP ベースのプロトコルを使用しているクライアントは、メッセージが待機中かどうかを判断するたに Web サーバを定期的に確認する必要があります。imq.httpjms.http.pullPeriod ブローカプロパティとそれに対応する imq.httpsjms.https.pullPeriod プロパティは、Message Queue クライアントが Web サーバをポーリングする頻度を指定します。
pullPeriod 値が -1 (デフォルト値) の場合、クライアントランタイムは直前の要求が戻るとすぐにサーバをポーリングし、個々のクライアントのパフォーマンスを最大化します。その結果、各クライアントコネクションが Web サーバ内の要求スレッドを 1 つずつ占有するため、Web サーバのリソースにかなりの負荷がかかる場合があります。
pullPeriod 値が正の数字である場合、クライアントランタイムは要求を定期的に Web サーバへ送信し、データが保留されているかどうかを確認します。この場合、クライアントは Web サーバの要求スレッドを占有しません。したがって、多数のクライアントが Web サーバを使用している場合は、pullPeriod を正の値に設定することで Web サーバのリソースを節約できます。
ファイルベースの持続ストアの調整
ファイルベースの持続ストアの調整については、「組み込み持続」を参照してください。
ブローカの調整
次の節では、パフォーマンスを改善するためにブローカのプロパティに対して実行できる調整について説明します。
メモリー管理 : 負荷のある状態でブローカの安定性を高める
メモリー管理は、送信先単位で、またはシステム全体に対し、すべての送信先を一括で設定できます。
送信先の制限の使い方
送信先の制限については、「送信先の管理」を参照してください。
システム全体の制限の使い方
メッセージプロデューサの処理速度がメッセージコンシューマの処理速度を上回る傾向がある場合には、メッセージをブローカに蓄積できます。ブローカにはメモリーが不足した場合に、プロデューサの処理速度を低下させ、アクティブメモリーからメッセージをスワップさせるメカニズムが組み込まれていますが (「メモリーリソースとメッセージフローの管理」を参照)、ブローカが保持可能なメッセージの合計数とメッセージのバイトの合計数に厳密な制限を設定した方が賢明です。
imq.system.max_count ブローカプロパティと imq.system.max_size ブローカプロパティを設定して、これらの制限を制御します。ブローカプロパティの設定方法については、「インスタンス設定ファイルの編集」または「imqbrokerd オプションの概要」を参照してください。
たとえば、次のように指定します。
上記で定義された値は、ブローカが未配信 / 未通知のメッセージを最大 5000 までしか保持しないことを示しています。それ以上のメッセージが送信されると、メッセージはブローカによって拒否されます。メッセージが持続的な場合は、プロデューサがメッセージを送信しようとすると例外を受け取ります。メッセージが持続的でない場合は、ブローカは暗黙のうちにメッセージを廃棄します。
持続性のないメッセージも持続性メッセージと同様に例外を戻すようにするには、クライアントが使用しているコネクションファクトリオブジェクトに次のプロパティを設定します。
上記の設定では、クライアントは次のメッセージを送信する前に応答を待機するため、持続性のないメッセージをブローカへ送信するときのパフォーマンスを低下させることがあります。しかし、通常、ブローカでのメッセージの受信はシステムのボトルネックにならないため、この低下は許容範囲内です。
メッセージの送信時に例外が戻った場合、クライアントは一時停止してから、送信を再試行します。
複数のコンシューマキューのパフォーマンス
複数のキューコンシューマがキュー送信先のメッセージを処理する効率は、設定可能なキュー送信先属性、すなわち、アクティブコンシューマの数 (maxNumActiveConsumers) とシングルバッチでコンシューマへ配信可能なメッセージの最大数 (consumerFlowLimit) によって左右されます。これらの属性は、表 6-10 に示されています。
最適なメッセージスループットを実現するには、十分な数のアクティブコンシューマがキューでのメッセージのプロデュースに遅れずに対応し、コンシュームする割合を最大にするような方法で、キュー内のメッセージをルートし、アクティブコンシューマへ配信しなければなりません。メッセージ配信を複数のコンシューマに分散させる一般的なメカニズムについては、「複数のコンシューマへのキュー配信」で説明されています。
メッセージがキューに蓄積している場合、メッセージ負荷を処理するアクティブコンシューマの数が不十分であることが考えられます。また、複数のメッセージがバッチサイズでコンシューマに配信されるため、メッセージがコンシューマ上でバックアップされていることも考えられます。たとえば、バッチサイズ (consumerFlowLimit) が大き過ぎる場合は、あるコンシューマがキュー内のすべてのメッセージを受信し、そのほかのコンシューマは何も受信していないことがあります。コンシューマが非常に高速であれば、これは問題にはなりません。
ただし、コンシューマが比較的低速で、メッセージをコンシューマに均等に分散させたい場合は、バッチサイズを小さくする必要があります。バッチサイズが小さいほど、メッセージをコンシューマへ配信するのに必要なオーバーヘッドは増加します。それでも、低速なコンシューマの場合は、一般に、小さいバッチサイズを使用した方がパフォーマンスは向上します。
クライアントランタイムのメッセージフローの調整
この節では、パフォーマンスに影響するフロー制御の動作について説明します (「クライアントランタイムの設定」を参照)。これらの動作は、コネクションファクトリの管理対象オブジェクトの属性として設定されます。コネクションファクトリ属性の設定方法については、第 7 章「管理対象オブジェクトの管理」を参照してください。
メッセージフロー測定
クライアントによって送受信されるメッセージ (JMS メッセージ) と Message Queue 制御メッセージは、同じクライアントとブローカ間のコネクションを使って伝送されます。ブローカ通知などの制御メッセージの配信における遅延は、JMS メッセージの配信によって制御メッセージが保留された場合に結果として生じます。このようなネットワークの輻輳を防止するため、Message Queue はコネクション全体の JMS メッセージのフローを測定します。
JMS メッセージは、設定した数だけ配信されるようにバッチされます (imqConnectionFlowCount プロパティの指定に従う)。つまり、バッチが配信されると、JMS メッセージの配信は中断され、保留中の制御メッセージが配信されます。JMS メッセージのそのほかのバッチが配信されるときも、このサイクルが繰り返され、その後、制御メッセージがキューに入れられます。
クライアントが、ブローカからの多数の応答を必要とする操作を実行している場合、たとえば、クライアントが CLIENT_ACKNOWLEDGE または AUTO_ACKNOWLEDGE モード、持続性メッセージ、トランザクション、キューブラウザを使用している場合や、クライアントがコンシューマを追加または削除する場合などには、imqConnectionFlowCount の値を小さいままにしておく必要があります。一方、クライアントが DUPS_OK_ACKNOWLEDGE モードを使用しており、コネクション上に単純なコンシューマしかいない場合は、パフォーマンスを犠牲にすることなく imqConnectionFlowCount の値を増やすことができます。
メッセージフロー制限
Message Queue クライアントランタイムがメモリーなどのローカルリソースの上限に達する前に処理可能な JMS メッセージの数には制限があります。この数に達すると、パフォーマンスに悪影響が出ます。したがって、Message Queue では、コンシューマあたりのメッセージ数またはコネクションあたりのメッセージ数を制限できます。この制限は、コネクションを介して配信し、クライアントランタイムにバッファし、コンシュームを待機できるメッセージの数を示しています。
コンシューマベースの制限
クライアントランタイムへ配信された JMS メッセージの数が、どれかのコンシューマの imqConsumerFlowLimit 値を超えた場合、そのコンシューマへのメッセージ配信は停止します。そのコンシューマのコンシュームされないメッセージの数が、imqConsumerFlowThreshold で設定された値を下回ったばあいにだけ、配信処理が再開されます。
次の例は、これらの制限の使い方を示しています。トピックコンシューマのデフォルト設定値を前提としています。
imqConsumerFlowLimit=1000
imqConsumerFlowThreshold=50
コンシューマが作成され、1000 のメッセージがあれば、ブローカはこれらのメッセージを最初のバッチとしてコンシューマに配信します。このとき一時停止はありません。1000 メッセージの送信後、ブローカはクライアントランタイムが追加のメッセージを要求するまで、配信を停止します。アプリケーションがこれらのメッセージを処理するまで、クライアントランタイムはそれらを保持します。その後、クライアントランタイムがブローカに次のバッチを送信するように要求するまでの間、アプリケーションは、少なくともメッセージバッファ容量の 50% (imqConsumerFlowThreshold) つまり 500 メッセージをコンシュームできます。
同じ状況で、しきい値が 10% の場合、クライアントランタイムは、アプリケーションが少なくとも 900 メッセージをコンシュームしてから、次のバッチを要求します。
次のバッチサイズの計算方法 :
そのため、imqConsumerFlowThreshold が 50% の場合、次のバッチサイズは、アプリケーションがメッセージを処理する速度に応じて 500 〜 1000 の間になります。
imqConsumerFlowThreshold がかなり高く (100% 近くに) 設定された場合、ブローカは比較的小さいサイズのバッチを送信するため、メッセージのスループットは低下することがあります。値が低過ぎる (0% に近い) 場合は、クライアントは次のセットを配信する前に残りのバッファされたメッセージの処理を完了してしまい、メッセージスループットを低下させることがあります。一般に、特定のパフォーマンスや信頼性を考慮しない限り、imqConsumerFlowThreshold 属性のデフォルト値を変更する必要はありません。
コンシューマベースのフロー制御、特に、imqConsumerFlowLimit は、クライアントランタイム内のメモリーを管理する最適な手段です。一般に、クライアントアプリケーションに応じて、コネクションでサポートする必要のあるコンシューマの数、メッセージのサイズ、クライアントランタイムで使用可能なメモリー総量がわかります。
コネクションベースの制限
一部のクライアントアプリケーションでは、エンドユーザーの選択によって、コンシューマの数が不確定が場合があります。そのような場合は、引き続き、コネクションレベルのフロー制限を使用してメモリーを管理できます。
コネクションレベルのフロー制御は、コネクション上のすべてのコンシューマについてバッファされたメッセージの合計数を制限します。この数が imqConnectionFlowLimit を超えると、合計数がコネクションの制限を下回るまで、コネクション経由のメッセージの配信は停止します。imqConnectionFlowLimit は、imqConnectionFlowLimitEnabled プロパティを true に設定した場合にだけ使用できます。
1 つのセッションでキューに入るメッセージの数は、そのセッションを使用するメッセージコンシューマの数と、各コンシューマのメッセージ負荷によって決まります。クライアント側のメッセージのプロデュースまたはメッセージのコンシュームに遅延が発生する場合は、通常は、アプリケーションを再設計し、より多くのセッションにメッセージプロデューサとメッセージコンシューマを分散し、またはより多くのコネクションにセッションを分散してパフォーマンスを改善できます。
