前へ 目次 索引 次へ |
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 サービスを使用したメッセージの配信

> 1. メッセージはプロデューシングクライアントからメッセージサーバへ配信される
> 2. メッセージサーバはメッセージの内容を読み取る
> 3. メッセージは、信頼性を維持するために持続ストレージに配置される
> 4. メッセージサーバは、信頼性を維持するためにメッセージの受信確認を発行する
> 5. メッセージサーバは、メッセージのルーティングを決定する
> 6. メッセージサーバはメッセージを書き込む
> 7. メッセージはメッセージサーバからコンシューミングクライアントへ配信される
> 8. コンシューミングクライアントは、信頼性を維持するためにメッセージの受信確認を発行する
> 9. メッセージサーバは、信頼性を維持するために、クライアントの通知を処理する
> 10. メッセージサーバは、クライアントの通知が処理されたことを通知する

> これらの手順は順次実行されるため、プロデューシングクライアントからコンシューミングクライアントへメッセージを配信する際には、どの手順もボトルネックとなる恐れがあります。これらの手順の大半は、メッセージングシステムの物理的な特性に依存しています。物理的な特性には、ネットワーク帯域幅、コンピュータの処理速度、メッセージサーバのアーキテクチャなどが含まれます。ただし、一部の手順は、メッセージングアプリケーションの特性と必要とされる信頼性のレベルにも依存しています。

> 次の節では、アプリケーション設計の要因とメッセージングシステムの要因の両方がパフォーマンスに及ぼす影響について説明します。アプリケーション設計の要因とメッセージングシステムの要因はメッセージの配信に密接に関係しますが、各カテゴリは個別に考慮します。

> ### パフォーマンスに影響するアプリケーション設計の要因

> アプリケーション設計の決定は、メッセージングのパフォーマンス全体に大きく影響することがあります。

> パフォーマンスに影響するもっとも重要な要因は、メッセージ配信の信頼性に影響を及ぼす要因です。次のような要因が含まれています。

> - 配信モード (持続的 / 持続性のないメッセージ)
> - トランザクションの使用
> - 通知モード
> - 永続的サブスクリプションと永続的でないサブスクリプション

> そのほかに、パフォーマンスに影響するアプリケーション設計の要因には、次のものがあります。

> - セレクタの使用 (メッセージのフィルタリング)
> - メッセージのサイズ
> - メッセージ本体のタイプ

> 以降の節では、これらの各要因がメッセージングパフォーマンスに及ぼす影響について説明します。原則として、パフォーマンスと信頼性は相反しています。つまり、信頼性が高くなるとパフォーマンスは低下します。

> 次の表は、さまざまなアプリケーション設計の要因が一般にどのようにメッセージングパフォーマンスに影響するかを示しています。表には、信頼性が高くパフォーマンスが低いシナリオと、パフォーマンスが高く信頼性の低いシナリオの 2 つのシナリオと、それぞれを特徴付ける主要なアプリケーション設計の要因を示します。これらの極端なシナリオの間には、信頼性とパフォーマンスの両方に影響する、多数の選択肢と兼ね合いがあります。

> 表 9-1 高信頼性シナリオと高パフォーマンスシナリオの比較

> アプリケーション設計要因 | 高信頼性 低パフォーマンスシナリオ | 高パフォーマンス 低信頼性シナリオ
> --- | --- | ---
> 配信モード | 持続性メッセージ | 持続性のないメッセージ
> トランザクションの使用 | 処理済みセッション | トランザクションなし
> 通知モード | AUTO_ACKNOWLEDGE または CLIENT_ACKNOWLEDGE | DUPS_OK_ACKNOWLEDGE
> 永続的 / 永続的でないサブスクリプション | 永続的サブスクリプション | 永続的でないサブスクリプション
> セレクタの使用 | メッセージのフィルタリング | メッセージのフィルタリングなし
> メッセージのサイズ | サイズの小さいメッセージ | サイズの大きいメッセージ
> メッセージ本体のタイプ | 複合本体タイプ | 単純本体タイプ

> 注 | 以下のグラフのパフォーマンスデータは、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 種類の概要を複雑な順に次に示します。

> - BytesMessage: 一連のバイトデータを含み、形式はアプリケーションによって決まる
> - TextMessage: 単純な java.lang.String
> - StreamMessage: Java プリミティブ値によるストリームを含む
> - MapMessage: 一連の名前と値のペアが含まれる
> - ObjectMessage: Java のシリアライズされたオブジェクトが含まれる

> 一般に、メッセージのタイプはアプリケーションのニーズによって決定され、MapMessage や ObjectMessage などのより複雑なタイプほどパフォーマンスは低下します。データのシリアライズとデシリアライズがパフォーマンスを低下させます。パフォーマンスは、データがどの程度単純か、またはどの程度複雑かによって異なります。

> ### パフォーマンスに影響するメッセージサービスの要因

> メッセージングアプリケーションのパフォーマンスは、アプリケーション設計だけでなく、メッセージのルーティングと配信を実行するメッセージサービスによっても影響を受けます。

> 次の節では、パフォーマンスに影響することのあるさまざまなメッセージサービスの要因について説明します。これらの要因の影響を理解しておくことは、メッセージサービスの内容を変更したり、配置済みのアプリケーションで発生することのあるパフォーマンスボトルネックを診断し解決したりする上で重要となります。

> Message Queue サービスのパフォーマンスに影響する最も重要な要因は、次のとおりです。

> - ハードウェア
> - オペレーティングシステム
> - Java 仮想マシン (JVM)
> - コネクション
> - ブローカの制限と動作
> - メッセージサービスのアーキテクチャ
> - データストアのパフォーマンス
> - クライアントランタイムの設定

> 以降の節では、これらの各要因がメッセージングパフォーマンスに及ぼす影響について説明します。

> #### ハードウェア

> 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 は、さまざまなプロトコルテクノロジのパフォーマンス特性を示しています。

> - TCPは、ブローカと通信する最速の方法を提供する
> - SSL は、メッセージの送信と受信に関しては、TCP より 50 〜 70% 低速である。持続性メッセージの場合は 50%、持続性のないメッセージの場合は約 70%。さらに、初期接続の確立は、SSL を使用した場合の方が低速で数秒かかる。これは、クライアントとブローカ、または HTTPS の場合は Web Server で、送信するデータの暗号化に使う非公開キーの作成が必要なためである。低レベルの各 TCP パケットの暗号化と復号化に必要な追加処理によって、パフォーマンスの低下が引き起こされる。

> 図 9-6 は、2 つのケースでの TCP と SSL のスループットを比較したものである。2 つのケースとは、1K バイトの持続性メッセージを、永続的サブスクリプションと AUTO_ACKNOWLEDGE 通知モードを使用しているトピック送信先へ送信する高信頼性シナリオと、1K バイトの持続性のないメッセージを、永続的サブスクリプションと DUPS_OK_ACKNOWLEDGE 通知モードを使用しているトピック送信先へ送信するハイパフォーマンスシナリオである

> 図 9-6 は、高信頼性ケースの方がプロトコルによる影響は少ないことを示す。これは、高信頼性のケースで必要な持続性メッセージのためのオーバーヘッドの方が、プロトコルの速度より、スループットを制限する重要な要因となるからである

> 図 9-6 トランスポートプロトコルによるパフォーマンスへの影響

> - HTTPは、TCP または SSL より低速である。HTTP ではクライアントとブローカ間のプロキシとして、Web サーバ上で実行しているサーブレットを使用する。パケットをHTTP 要求へカプセル化する必要がある点と、メッセージがブローカへ到達するには、クライアントからサーブレットへ、サーブレットからブローカへという 2 つの段階が必要である点から、パフォーマンスへのオーバーヘッドが発生する
> - HTTPS は HTTP より低速である。これは、クライアントとサーブレット間、およびサーブレットとブローカ間でパケットを暗号化するためにオーバーヘッドが必須となるからである

> #### メッセージサービスのアーキテクチャ

> 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)
> - Message Queueブローカログファイル
> - メッセージベースの監視 API

> 次の節では、これらの各ツールを使用してメトリックス情報を取得する方法を説明します。さまざまなツールの比較については、「適切な監視ツールの選択」を参照してください。

> #### Message Queueコマンドユーティリティ (imqcmd)

> コマンドユーティリティ (imqcmd) は、Message Queue の基本的なコマンド行管理ツールです。このツールを使用して、ブローカとブローカのコネクションサービス、およびアプリケーション固有のリソースである物理的な送信先、永続的サブスクリプション、トランザクションなどを管理できます。imqcmd コマンドについては、第 6 章「ブローカとアプリケーションの管理」で説明されています。

> imqcmd コマンドの機能の 1 つは、ブローカ全体、個々のコネクションサービス、個々の送信先に関するメトリックス情報を取得できる機能です。メトリックスデータを取得するには、一般に、imqcmd の metrics サブコマンドを使用します。メトリックスデータは、指定した間隔で、または指定した回数だけ、コンソール画面に表示されます。

> また、query サブコマンド (「imqcmd query」を参照) を使用して、より限定されたメトリックスデータのサブセットを取得することもできます。

> ##### imqcmd metrics

> imqcmd metrics の構文とオプションを、それぞれ表 9-2 と表 9-3 に示します。

> 表 9-2 imqcmd metrics サブコマンドの構文

> サブコマンドの構文 | 提供されるメトリックスデータ
> --- | ---
> metrics bkr [-b hostName:port] [-m metricType] [-int interval] [-msp numSamples] [-u userName [-p pasword | デフォルトのブローカ、または指定したホストとポートのブローカに対して、ブローカのメトリックスを表示する
> または |
> metrics svc -n serviceName [-b hostName:port] [-m metricType] [-int interval] [-msp numSamples] [-u userName [-p pasword | デフォルトのブローカ、または指定したホストとポートのブローカで実行している特定のサービスのメトリックスを表示する
> または |
> metrics dst -t destType -n destName [-b hostName:port] [-m metricType] [-int interval] [-msp numSamples] [-u userName [-p pasword | 特定のタイプと名前の送信先に関するメトリックス情報を表示する

> 表 9-3 imqcmd metrics サブコマンドのオプション

> サブコマンドのオプション | 説明
> --- | ---
> -b hostName:port | メトリックスデータを報告するホスト名とブローカのポートを指定する デフォルト値は localhost:7676
> -int interval | メトリックスが表示される間隔を、秒単位で指定する デフォルトは 5 秒
> -m metricType | 表示するメトリックスのタイプを指定する ttl ブローカとの間のメッセージとパケットのフローに関するメトリックスを表示する (デフォルトのメトリックスタイプ) rts ブローカとの間のメッセージとパケットの 1 秒あたりのフローの量に関するメトリックスを表示する cxn コネクション、仮想メモリーヒープ、およびスレッドを表示する (ブローカとコネクションサービスだけ) con コンシューマ関連のメトリックスを表示する (送信先だけ) dsk ディスク使用量のメトリックスを表示する (送信先だけ)
> -msp numSamples | 出力に表示するサンプルの数を指定する。デフォルトは無制限 (無限)
> -n destName | 必要に応じて、メトリックスデータを報告する送信先の送信先名を指定する。デフォルトはない
> -n serviceName | 必要に応じて、メトリックスデータを報告するコネクションサービスを指定する。デフォルトはない
> -t destTyp | 必要に応じて、メトリックスデータを報告する送信先のタイプ (キューまたはトピック) を指定する。デフォルトはない
> -u userName | 管理者名を指定する。この値を省略すると、管理者名の入力を要求される
> -p password | 管理者パスワードを指定する。この値を省略すると、管理者名の入力を要求される

> ##### 手順 : metrics サブコマンドを使用したメトリックスデータの表示

> この節では、metrics サブコマンドを使用してメトリックス情報を報告するための手順を説明します。

> ##### metrics サブコマンドを使用するには

> 1. メトリックス情報が必要なブローカを起動します。

> 「ブローカの起動」を参照してください。

> 2. 表 9-2 と表 9-3 に示すオプションを指定して、適切な imqcmd metrics サブコマンドを実行します。

> ##### メトリックスの出力 : imqcmd metrics

> この節では、ブローカ全体、コネクションサービス、送信先のメトリックスに関する metrics サブコマンドの出力例を示します。

> ブローカ全体のメトリックス ブローカとの間のメッセージとパケットのフローレートを 10 秒間隔で取得するには、metrics bkr サブコマンドを使用します。

> imqcmd metrics bkr -m rts -int 10 -u admin -p admin

> このコマンドは、次のような出力を生成します (表 9-8 のデータの説明を参照)。

> --------------------------------------------------------
> Msgs/sec Msg Bytes/sec Pkts/sec Pkt Bytes/sec
> In Out In Out In Out In Out
> --------------------------------------------------------
> 0 0 27 56 0 0 38 66
> 10 0 7365 56 10 10 7457 1132
> 0 0 27 56 0 0 38 73
> 0 10 27 7402 10 20 1400 8459
> 0 0 27 56 0 0 38 73

> コネクションサービスのメトリックス jms コネクションサービスが処理したメッセージとパケットの累計を取得するには、metrics svc サブコマンドを使用します。

> imqcmd metrics svc -n jms -m ttl -u admin -p admin

> このコマンドは、次のような出力を生成します (表 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 サブコマンドを使用します。

> imqcmd metrics dst -t q -n XQueue -m ttl -u admin -p admin

> このコマンドは、次のような出力を生成します (表 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 サブコマンドを使用します。

> imqcmd metrics dst -t q -n SimpleQueue -m con -u admin -p admin

> このコマンドは、次のような出力を生成します (表 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 デーモンプロセスなどの多数の出力チャネルに書き込みます。ロガーについては、「ロガー」で説明されています。

> ロガーが収集する情報のタイプと、各出力チャネルに書き込む情報のタイプを指定できます。特に、メトリックス情報のログファイルへの書き込みを指定できます。

> ##### 手順 : ブローカログファイルを使用したメトリックスデータの報告

> この節では、ブローカログファイルを使用してメトリックス情報を報告するための手順を説明します。ロガーの設定方法については、「ログ作成」を参照してください。

> ##### ログファイルを使用してメトリックス情報を報告するには

> 1. ブローカのメトリックス生成機能を設定します。
> 1. imq.metrics.enabled=true に設定されていることを確認します。

> デフォルトでは、ログ用のメトリックスの生成は有効になっています。

> 2. メトリックスの生成間隔を適切な秒数に設定します。

> imq.metrics.interval=interval

> この値は、config.properties ファイル内で設定するか、または、 ブローカの起動時に -metrics interval コマンド行オプションを使用して設定できます。

> 2. ロガーがメトリックス情報を収集していることを確認します。

> imq.log.level=INFO

> デフォルト値 は true この値は、config.properties ファイル内で設定するか、または、ブローカの起動時に -loglevel level コマンドオプションを使用して設定できます。

> 3. ロガーが、メトリックス情報をログファイルへ書き込むように設定されていることを確認します。

> imq.log.file.output=INFO

> これはデフォルト値です。config.properties ファイル内で設定できます。

> 4. ブローカを起動します。

> ##### メトリックスの出力 : ログファイル

> 次は、ログファイルに出力されたブローカメトリックスのサンプルを示しています (表 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 | 指定した名前のトピックの送信先メトリックス

> ##### 手順 : メッセージベースの監視の設定

> この節では、メッセージベースの監視機能を使用してメトリックス情報を収集するための手順を説明します。手順には、クライアント開発タスクと管理タスクの両方が含まれます。

> ##### メッセージベースの監視を設定するには

> 1. メトリックス監視クライアントを作成します。

> メトリックストピック送信先へサブスクライブし、メトリックスメッセージをコンシュームし、これらのメッセージからメトリックスデータを抽出するクライアントをプログラミングする手順については、『Message Queue Java Client Developer's Guide』を参照してください。

> 2. config.properties ファイルにブローカプロパティ値を設定して、ブローカのメトリックスメッセージプロデューサを設定します。
> 1. メトリックスメッセージのプロデュースを有効にする

> imq.metrics.topic.enabled=true と設定する

> デフォルト値は true

> 2. メトリックスメッセージを生成する間隔を、秒単位で指定する

> imq.metrics.topic.interval=interval と設定する

> デフォルトは 60 秒

> 3. メトリックスメッセージを持続的にするかどうか、つまり、ブローカ障害時にもそのまま保持するかどうかを指定する

> imq.metrics.topic.persist を設定する

> デフォルト値は false

> 4. 各送信先で、メトリックスメッセージを削除するまでに保持しておく期間を指定する

> Set imq.metrics.topic.timetolive

> デフォルト値は 300 秒

> 3. メトリックストピック送信先に必要なアクセス制御を設定します。

> 設定方法は次の、「セキュリティとアクセスで考慮すること」を参照してください。

> 4. メトリックス監視クライアントを起動します。

> コンシューマがメトリックストピックをサブスクライブすると、メトリックストピック送信先が自動的に作成されます。メトリックストピックが作成されると、ブローカのメトリックスメッセージプロデューサがメトリックスメッセージをメトリックストピックへ送信し始めます。

> ##### セキュリティとアクセスで考慮すること

> メトリックストピック送信先へのアクセスを制限する理由は 2 つあります。

> - メトリックスデータにブローカとそのリソースに関する機密情報が含まれることがある
> - メトリックストピック送信先へのサブスクリプション数が過剰になると、ブローカのオーバーヘッドが増加し、ペフォーマンスに悪影響を及ぼすことがある

> これらの点を考慮して、メトリックストピック送信先へのアクセスは制御することをお勧めします。

> 監視クライアントは、そのほかのクライアントと同じ認証制御と権限を前提にしています。ブローカへの接続が許可されるのは、Message Queue ユーザーリポジトリに登録されているユーザーだけです。

> 「ユーザーの承認 : アクセス制御プロパティファイル」に説明されているとおり、アクセス制御プロパティファイルを使用して特定のメトリックストピック送信先へのアクセスを制限することで、さらに保護を強化できます。

> たとえば、accesscontrol.properties ファイル内の次のエントリは、user1 と user2 を除き、すべてのユーザーについて mq.metrics.broker メトリックストピックへのアクセスを拒否します。

> topic.mq.metrics.broker.consume.deny.user=* topic.mq.metrics.broker.consume.allow.user=user1,user2

> 次のエントリは、ユーザー 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 | リモート監視 対象となる特定のデータを容易に選択できる データを電子的に分析し、任意の形式で提示できる | ブローカプロパティの設定が必要。有効にするにはブローカをシャットダウンし再起動する必要がある 専用のメトリックス監視クライアントをプログラミングする必要がある 報告間隔を即座に変更できない。すべてのメトリックスデータについて同じ

> ### メトリックスデータの送信先

> ブローカによって報告されるメトリックス情報は、次のカテゴリにグループ化できます。

> - Java 仮想マシン (JVM) メトリックス JVM ヒープサイズに関する情報
> - ブローカ全体のメトリックス ブローカに格納されたメッセージ、ブローカとの間のメッセージフロー、メッセージ数とバイト数 (絶対値と比較値) の両方に関する情報。このカテゴリには、メモリー使用量に関する情報も含まれます。
> - コネクションサービスのメトリックス コネクションとコネクションスレッドのリソースに関する情報、および特定のコネクションサービスのメッセージフローに関する情報
> - 送信先のメトリックス 特定の送信先との間のメッセージフロー、送信先のコンシューマ、メモリーとディスクスペースの使用率に関する情報

> 次の節では、これらの各カテゴリで使用可能なメトリックスデータについて取り上げます。次の表に記載されている監視ツールについては、「監視ツール」を参照してください。

> #### JVM メトリックス

> 表 9-7 は、JVM ヒープを処理するためにブローカが生成するメトリックスとその説明、さらに各種監視ツールを使用してどのデータを取得できるかを一覧しています。

> 表 9-7 JVM メトリックス

> メトリックス量 | 説明 | imqcmd metrics bkr (metricType) | ログファイル | メトリックスメッセージ (metrics topic)1
> --- | --- | --- | --- | ---
> JVM heap: free memory | JVM ヒープに使用可能な空きメモリー量 | 必須 (cxn) | 必須 | 必須 (...jvm)
> JVM heap: total memory | 現在の JVM ヒープサイズ | 必須 (cxn) | 必須 | 必須 (...jvm)
> JVM heap: max memory | JVM ヒープサイズを拡大可能な上限 | オプション | 必須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)

> 1メトリックスのトピック送信先名については、表 9-5 を参照

> #### コネクションサービスのメトリックス

> 表 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)

> 1メトリックスのトピック送信先名については、表 9-5 を参照

> ##

> パフォーマンス問題のトラブルシューティング

> Message Queue サービスを使用してアプリケーションをサポートする際に発生する恐れのある多数のパフォーマンス問題があります。このような問題には次のものが含まれます。

> - 問題 : クライアントがコネクションを確立できない
> - 問題 : コネクションスループットが遅過ぎる
> - 問題 : クライアントがメッセージプロデューサを作成できない
> - 問題 : メッセージのプロデュースが遅れるまたは低速である
> - 問題 : メッセージサーバでメッセージがバックログされる
> - 問題: メッセージサーバのスループットが散発的である
> - 問題 : メッセージがコンシューマに到達しない

> 各問題を取り上げ、その考えられる原因と解決方法を説明します。

> ### 問題 : クライアントがコネクションを確立できない

> #### 現象 :

> - クライアントが新しいコネクションを確立できない
> - クライアントが障害の生じたコネクションを自動的に再接続できない

> #### 考えられる原因 :

> - クライアントアプリケーションがコネクションを閉じていないため、コネクション数がリソース制限を越えてしまった

> この問題の原因を確認するには :

> ブローカへのコネクションをすべて一覧表示します。

> imqcmd list cxn

> 出力にはすべてのコネクションと各コネクションの確立元のホストが一覧表示されます。異常な数のコネクションが開かれている特定のクライアントがわかります。

> 問題を解決するには

> 原因となっているクライアントが未使用のコネクションを閉じるようにプログラムし直します。

> - ブローカが実行されていないか、ネットワーク接続の問題が存在している

> この問題の原因を確認するには

> - ブローカのプライマリポートへ telnet で接続し、ブローカがポートマッパー出力を返すか確認します。プライマリポートのデフォルトは 7676 です。
> - ブローカプロセスがホスト上で実行されていることを確認します。

> 問題を解決するには

> - ブローカを起動します。
> - ネットワーク接続の問題を修復します。
> - コネクションサービスが非アクティブであるか停止される

> この問題の原因を確認するには

> すべてのコネクションサービスのステータスを確認します。

> imqcmd list svc

> コネクションサービスのステータスが unknown または paused と表示された場合、クライアントはそのサービスを使用するコネクションを確立できません。

> 問題を解決するには

> - コネクションサービスのステータスが unknown と表示された場合、そのサービスはアクティブサービスリスト (imq.service.active) に含まれていません。SSL ベースのサービスの場合は、サービスが不適切に設定されているため、ブローカがブローカログに次のエントリを作成する可能性があります。ERROR [B3009]: Unable to start service ssljms:[B4001]: Unable to open protocol tls for ssljms service... 例外の根本的な原因の説明が続きます。

> SSL サービスを適切に設定する方法については、「TCP/IP を介した SSL ベースのサービスの設定」を参照してください。

> - コネクションサービスのステータスが paused と表示された場合は、サービスを再開します (「コネクションサービスの停止および再開」を参照)。
> - 必要なコネクション数に対して使用可能なスレッドが少な過ぎる

> この問題の原因を確認するには

> ブローカログの次のエントリを確認します。WARNING [B3004]: No threads are available to process a new connection on service ... Closing the new connection.

> また、コネクションサービスのコネクション数と現在使用中のスレッド数を確認します。

> imqcmd query svc -n serviceName
> または
> imqcmd metrics svc -n serviceName -m cxn

> コネクションごとに 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 で定義されるファイル記述子の制限事項」を参照)

> この問題の原因を確認するには

> 次のようなブローカログのエントリを確認します。Too many open files.

> 問題を解決するには

> マニュアルの ulimit で説明しているとおり、ファイル記述子の制限を増やします。

> - TCP バックログにより、確立可能な新しい同時コネクション要求の数が制限される

> TCP バックログが、同時コネクション要求の数を制限する。ポートマッパーが追加要求を拒否しなければ、同時コネクション要求はシステムバックログ (imq.portmapper.backlog) に格納される。Windows プラットフォームでは、バックログ制限は固定されていて、 Windows クライアントでは 5、Windows サーバでは 200 に制限されている

> 通常、バックログ制限が原因の要求拒否は過渡的な現象であり、非常に多数の同時コネクション要求があると発生する

> この問題の原因を確認するには

> ブローカログで、一部のコネクション要求は受け入れられたが、ほぼ同時に受け取ったほかのコネクション要求が拒否されていないかどうかを確認します。拒否されたコネクション要求は、java.net.ConnectException: Connection refused を返します。

> 問題を解決するには

> 次の手順で、TCP バックログ制限を解消できます。

> - クライアントが確立しようとするコネクションの再試行を短い間隔で行うようにプログラミングします。この問題の過渡的な性質上、このようにプログラミングしても正常に動作します。
> - imq.portmapper.backlog の値を大きくします。
> - クライアントがコネクションを閉じずに、多くのコネクションを開いていないか確認します。
> - オペレーティングシステムによって同時コネクションの数が制限される

> Windows オペレーティングシステムのライセンスは、サポートされる同時リモートコネクションの数を制限する

> この問題の原因を確認するには

> imqcmd query svc を使用して、コネクション用のスレッドが十分にあることを調べ、さらに Windows ライセンス契約書の条項を確認します。ローカルクライアントからはコネクションを確立できるが、リモートクライアントからは確立できない場合は、オペレーティングシステムの制限が問題の原因と考えられます。

> 問題を解決するには

> - より多くのコネクションが許可されるように Windows ライセンスをアップグレードします。
> - マルチブローカクラスタを設定して、多数のブローカインスタンスにコネクションを分散します。
> - ユーザーの認証に失敗するか権限が与えられない

> 不正なパスワード、ユーザーリポジトリにユーザーのエントリがない、またはユーザーがコネクションサービスへのアクセス許可を持っていないといった原因で、認証は失敗することがあります。

> この問題の原因を確認するには

> ブローカログのエントリで Forbidden エラーメッセージを確認します。このメッセージは、認証エラーを示しているだけで、その理由は示していません。

> - ファイルベースのユーザーリポジトリを使用している場合は、次のコマンドを入力します。

> imqusermgr list -i instanceName -u userName

> 出力にユーザーが表示された場合は、不正なパスワードの入力が原因と考えられます。出力に、[B3048]: User does not exist in the password file と表示された場合は、ユーザーリポジトリにエントリがありません。

> - LDAP サーバのユーザーリポジトリを使用している場合は、適切なツールを使用して、ユーザーのエントリがあるかどうかを確認します。
> - アクセス制御プロパティファイルで、コネクションサービスへのアクセスが制限されていないかどうかを確認します。

> 問題を解決するには

> - ユーザーリポジトリにユーザーのエントリがない場合は、ユーザーリポジトリにユーザーを追加します (「ユーザーリポジトリの設定と管理」を参照)。
> - 不正がパスワードが使用された場合は、正しいパスワードを入力し直します。
> - アクセス制御プロパティが不正に設定されていた場合は、アクセス制御プロパティファイルを編集し、コネクションサービスへのアクセス許可を与えます (「コネクションアクセス制御」を参照)。

> ### 問題 : コネクションスループットが遅過ぎる

> #### 現象 :

> - メッセージスループットが期待どおりでない
> - サポートされるブローカへのコネクション数は、「問題 : クライアントがコネクションを確立できない」で説明したように制限されているわけではなく、メッセージの入力 / 出力レートによって制限されている

> #### 考えられる原因 :

> - ネットワークコネクションまたは WAN が遅過ぎる

> この問題の原因を確認するには

> ネットワークへ ping し、ping が戻るまでに要する時間を確認し、ネットワーク管理者に相談します。また、ローカルクライアントを使用してメッセージを送受信し、ネットワークリンク経由でリモートクライアントを使用した場合と配信時間を比較することもできます。

> 問題を解決するには

> コネクションが遅過ぎる場合は、ネットワークリンクをアップグレードします。

> - コネクションサービスプロトコルは、TCP に比べ、本質的に低速です。たとえば、SSL ベースのプロトコルや HTTP ベースのプロトコルは、TCP より低速です (図 9-5を参照)。

> この問題の原因を確認するには

> SSL ベースのプロトコルまたは HTTP ベースのプロトコルを使用している場合は、TCP を使用して配信時間を比較してみます。

> 問題を解決するには

> 通常、アプリケーション要件によって使用するプロトコルが決定されます。そのため、「トランスポートプロトコルの調整」の説明にしたがいプロトコルを調整する以外に、対象方法はほとんどありません。

> - コネクションサービスプロトコルが最適に調整されていない

> この問題の原因を確認するには

> プロトコルを調整し、違いが生じるかどうかを確認します。

> 問題を解決するには

> 「トランスポートプロトコルの調整」の説明にしたがいプロトコルを調整します。

> - メッセージのサイズが大きく、多くの帯域幅を占有してしまう

> この問題の原因を確認するには

> 小さいサイズのメッセージでベンチマークを実行します。

> 問題を解決するには

> - java.util.zip を使用してメッセージの本体を圧縮します。
> - データを送信することの通知としてメッセージを使用し、データの送信には別のプロトコルを使用します。
> - コネクションスループットが低速であるように見えるが、実際は、メッセージ配信プロセスのほかの手順にボトルネックがある

> この問題の原因を確認するには

> コネクションスループットが低速であるように見えるが、前に述べたような原因が見当たらない場合は、図 9-1 を参照して、そのほかの考えられるボトルネックを特定し、次の問題に関連する現象が出ていないかどうかを確認します。

> - 「問題 : メッセージのプロデュースが遅れるまたは低速である」
> - 「問題 : メッセージサーバでメッセージがバックログされる」
> - 「問題: メッセージサーバのスループットが散発的である」

> 問題を解決するには

> 前に述べた問題のトラブルシューティングの節に記載された問題の解決方法に従います。

> ### 問題 : クライアントがメッセージプロデューサを作成できない

> #### 現象 :

> - メッセージプロデューサが送信先に対して作成できず、クライアントは例外を受け取った

> #### 考えられる原因 :

> - 限定された数のプロデューサだけを許可するように送信先が設定されている

> 送信先でのメッセージの蓄積を回避する 1 つの方法は、送信先がサポート可能なプロデューサの数を (maxNumProducers) で限定することです。

> この問題の原因を確認するには

> 送信先を確認します (「送信先情報の表示」を参照)。

> imqcmd query dst

> 出力に現在のプロデューサ数と 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

> 問題を解決するには

> ユーザーがメッセージをプロデュースできるようにアクセス制御プロパティを変更します (「送信先アクセス制御」を参照)。

> ### 問題 : メッセージのプロデュースが遅れるまたは低速である

> #### 現象 :

> - 持続性メッセージを送信したときに、send() メソッドが戻らずクライアントがブロックする
> - 持続性メッセージを送信したときに、クライアントが例外を受け取る
> - プロデューシングクライアントの処理速度が低下する

> #### 考えられる原因 :

> - メッセージサーバがバックログされ、メッセージがブローカメモリーに蓄積されており、処理速度の低下したメッセージプロデューサが応答している

> 送信先メモリー内のメッセージ数またはメッセージのバイト数が設定された制限に達すると、ブローカは指定された制限の動作に従いメモリーリソースを節約しようとします。次の制限の動作により、メッセージプロデューサの処理速度が低下します。

> - FLOW_CONTROL : ブローカが持続性メッセージの受信を即時に通知しないため、プロデューシングクライアントがブロックされる
> - REJECT_NEWEST : ブローカが新しいメッセージを拒否し、拒否された持続性メッセージごとに例外をスローする

> 同様に、ブローカ全体のメモリー内 (すべての送信先に対応) のメッセージ数またはメッセージのバイト数が設定済みの制限に達すると、ブローカは最新のメッセージを拒否してメモリーリソースを節約しようとします。

> また、送信先またはブローカ全体の制限が適切に設定されていないために、システムメモリーの制限に達すると、ブローカはメッセージプロデューサを徐々に減らすなどのさらに重大なアクションを実行してメモリーの過負荷を防ぎます。

> これらのメカニズムについては、「メモリーリソースとメッセージフローの管理」を参照してください。

> この問題の原因を確認するには

> 設定済みのメッセージの制限が原因でブローカによってメッセージが拒否された場合は、ブローカが JMSException [C4036]: A server error occurred を返し、ブローカログに次のエントリを作成します。WARNING [B2011]: Storing of JMS message from IMQconn failed に続き、制限に達したことを示すメッセージが表示されます。

> - 送信先上でメッセージが制限されている場合は、ブローカは次のようなエントリを作成する [B4120]: Can not store message on destination destName because capacity of maxNumMsgs would be exceeded.
> - ブローカ全体でメッセージが制限されている場合は、ブローカは次のようなエントリを作成する [B4024]: The Maximum Number of messages currrently in the system has been exceeded, rejecting message.

> 多くの場合は、送信先とブローカにクエリーし設定済みのメッセージ制限の設定値を検査するか、送信先またはブローカ全体の現在のメッセージ数とメッセージのバイト数を監視し適切な imqcmd コマンドを使用することで、拒否される前にメッセージの制限条件を確認できます (それぞれ、表 9-10 と表 9-8 を参照)。

> 問題を解決するには

> メッセージがバックログされたことでプロデューサの処理が低下する問題を解消するためのアプローチは多数あります。

> - 送信先またはブローカ全体のメッセージ制限がメモリーリソースを超えないように注意深く変更する。一般に、ブローカ全体のメセージ制限に達しないように、送信先単位でメモリーを管理した方が良い。詳細は、「ブローカの調整」を参照
> - メッセージ制限に達したときに、メッセージのプロデュースが低速化しないようにする代わりに、メモリー内のメッセージを廃棄するよう、送信先の制限の動作を変更する。たとえば、メモリーに累積されたメッセージを削除する REMOVE_OLDEST および REMOVE_LOW_PRIORITY といった制限の動作を指定できる (表 6-10 を参照)
> - ブローカは持続性メッセージをデータストアに保存できない

> ブローカがデータストアにアクセスできないか、または持続性メッセージをデータストアに書き込めない場合は、プロデューシングクライアントがブロックされます。前に述べたとおり、この状態は、送信先またはブローカ全体のメッセージ制限に達したときにも発生します。

> この問題の原因を確認するには

> ブローカは、データストアに書き込めない場合には、ブローカログに次のエントリのどれかを作成します。[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 制限に達している

> この問題の原因を確認するには

> - クライアントアプリケーションが Out of Memory エラーを受け取ったかどうかを確認する
> - freeMemory()、MaxMemory()、および totalMemory() などのランタイムメソッドを使用して JVM ヒープの使用可能な空きメモリーを確認する

> 問題を解決するには

> JVM を調整します (「Java 仮想マシン (JVM) の調整」を参照)。

> ### 問題 : メッセージサーバでメッセージがバックログされる

> #### 現象 :

> - ブローカまたは特定の送信先のメッセージ数またはメッセージのバイト数が時間の経過とともに徐々に増えていく

> メッセージが蓄積されているかどうかを確認するため、ブローカ内のメッセージ数またはメッセージのバイト数が時間の経過とともにどのように変化するかを確認し、設定済みの制限と比較します。最初に、設定済みの制限を確認します。

> imqcmd query bkr

> 注 : imqcmd metrics bkr サブコマンドは、この情報を表示しません。

> その後、各送信先でのメッセージの蓄積を確認します。

> imqcmd query dst -t destType -n destName
> または
> imqcmd metrics dst -t destType -n destName -m ttl

> メッセージが設定済みの送信先またはブローカ全体の制限を越えているかどうかを判断するため、ブローカログで次のエントリを確認します。WARNING [B2011]: Storing of JMS message from...failed. このエントリには、制限を越えたことを示す別のエントリが続きます。

> - メッセージのプロデュースが遅い、またはプロデュースされたメッセージがブローカによって拒否される
> - メッセージがコンシューマに到達するまでに異常に長い時間がかかる

> #### 考えられる原因 :

> - クライアントコードの欠陥 : コンシューマがメッセージを通知していない

> メッセージは、すべてのコンシューマによってメッセージの送信先へ通知されるまで、送信先で保持されます。したがって、クライアントがコンシュームしたメッセージを通知しない場合、メッセージは削除されずに送信先で蓄積されます。

> たとえば、クライアントコードは次の欠陥を持っている可能性があります。

> - CLIENT_ACKNOWLEDGEMENT または処理済みセッションを使用しているコンシューマが、定期的に Session.acknowledge() または Session.commit() を呼び出していない可能性がある
> - AUTO_ACKNOWLEDGE セッションを使用しているコンシューマが何らかの理由で停止している可能性がある

> この問題の原因を確認するには

> メッセージサーバの負荷が高くない場合、つまり、送信先との間のメッセージのフローレートが低い場合は、通知されていないため、メッセージが蓄積されている可能性があります。

> ブローカとの間のメッセージのフローレートを確認します。

> imqcmd metrics bkr -m rts

> その後、個々の送信先についてそれぞれのフローレートを確認します。

> imqcmd metrics bkr -t destType -n destName -m rts

> また、メッセージが正しく通知されているかどうかを判断するため、クライアントコードを確認します。

> - トピック送信先に非アクティブな永続的サブスクリプションがある

> 永続的サブスクリプションが非アクティブな場合は、該当するコンシューマがアクティブになりメッセージをコンシュームできるようになるまで、メッセージは送信先に格納されます。

> この問題の原因を確認するには

> 各トピック送信先の永続的サブスクリプションの状態を確認します。

> imqcmd list dur -d destName

> 問題を解決するには

> 次のアクションのどれかを実行できます。

> - 原因となっている永続的サブスクリプションのすべてのメッセージをパージする (「永続サブスクリプションの管理」を参照)
> - トピックのメッセージの制限と制限の動作属性を指定する (表 6-10 を参照)。たとえば、メモリーに累積されたメッセージを削除する REMOVE_OLDEST および REMOVE_LOW_PRIORITY といった制限の動作を指定できる
> - 該当する送信先からすべてのメッセージをパージする (「送信先のパージ」を参照)
> - メッセージをメモリー内で存続できる時間を制限する。プロデューシングクライアントをプログラムし直し、メッセージごとに生存時間の値を設定できる。imqOverrideJMSExpiration および imqJMSExpiration コネクションファクトリ属性を設定することで、コネクションを共有するすべてのプロデューサのこれらの設定値をオーバーライドできる (表 7-3 を参照)
> - キュー内のメッセージをコンシュームするために使用可能なコンシューマが少な過ぎる

> メッセージを配信可能なアクティブなコンシューマが少な過ぎる場合は、メッセージが蓄積するにつれ、キュー送信先がバックログされる恐れあります。この状態は、次の理由のどれかが原因で発生することがあります。

> - 送信先に対応するアクティブなコンシューマが少な過ぎる
> - コンシューミングクライアントがコネクションの確立に失敗した
> - アクティブなコンシューマがキュー内のメッセージに一致するセレクタを使用していない

> この問題の原因を確認するには

> コンシューマ使用できない理由を判断するために、送信先のアクティブなコンシューマの数を確認します。

> imqcmd metrics dst -n destName -t q -m con

> 問題を解決するには

> コンシューマが使用できない理由に応じて、次のアクションのどれかを実行できます。

> - 追加のコンシューミングクライアントを起動して、キューに対応するアクティブなコンシューマを増やす
> - imq.consumerFlowLimit ブローカプロパティを調整して、複数のコンシューマへのキュー配信を最適化する (「複数のコンシューマキューのパフォーマンス」を参照)
> - キューのメッセージの制限と制限の動作属性を指定する (表 6-10 を参照)。たとえば、メモリーに累積されたメッセージを削除する REMOVE_OLDEST および REMOVE_LOW_PRIORITY といった制限の動作を指定できる
> - 該当する送信先からすべてのメッセージをパージする (「送信先のパージ」を参照)
> - メッセージをメモリー内で存続できる時間を制限する。プロデューシングクライアントをプラグらミングし直し、メッセージごとに生存期間の値を設定できる。imqOverrideJMSExpiration および imqJMSExpiration コネクションファクトリ属性を設定することで、コネクションを共有するすべてのプロデューサのこれらの設定値をオーバーライドできる (表 7-3 を参照)
> - メッセージプロデューサの処理速度についていくには、メッセージコンシューマの処理速度が遅過ぎる

> この場合、トピックのサブスクライバまたはキューの受信側は、プロデューサがメッセージを送信する速度より遅い速度でメッセージをコンシュームしています。この不均衡が原因で、複数の送信先にメッセージがバックログされています。

> この問題の原因を確認するには

> ブローカとの間のメッセージのフローレートを確認します。

> imqcmd metrics bkr -m rts

> その後、個々の送信先についてそれぞれのフローレートを確認します。

> imqcmd metrics bkr -t destType -n destName -m rts

> 問題を解決するには

> - コンシューミングクライアントコードを最適化する
> - キュー送信先の場合は、アクティブなコンシューマの数を増やす (「複数のコンシューマキューのパフォーマンス」を参照)
> - クライアントの通知処理が、メッセージのコンシュームを遅くする

> クライアントの通知処理には 2 つの要因が影響しています。

> - クライアント通知の処理時に、大量のブローカリソースが使用されることがある。その結果、このような通知モードでは、ブローカがクライアント通知を確認するまでコンシューミングクライアントがブロックされるので、メッセージのコンシュームが遅くなることがある。
> - JMS ペイロードメッセージと、クライアント通知などの Message Queue 制御メッセージは同じコネクションを共有する。その結果、制御メッセージが JMS ペイロードメッセージによって保留され、メッセージのコンシュームを低速化させることがある。

> この問題の原因を確認するには

> メッセージのフローをパケットのフローと比較して確認します。1秒当たりのパケット数がメッセージの数と比例していない場合は、クライアントの通知が問題と考えられます。

> また、クライアントが JMSException [C4000]: Packet acknowledge failed メッセージを受信したかどうかを確認します。

> 問題を解決するには

> - クライアントの通知モードを変更する。たとえば、DUPS_OK_ACKNOWLEDGEMENT または CLIENT_ACKNOWLEDGEMENT に切り換える
> - CLIENT_ACKNOWLEDGEMENT または処理済みのセッションを使用している場合は、より多数のメッセージを単一の通知にグループ化する
> - コンシューマとコネクションのフロー制御パラメータを調整する (「クライアントランタイムのメッセージフローの調整」を参照)
> - ブローカがプロデュースされたメッセージの処理に追いつけない

> この場合、ブローカがメッセージをコンシューマにルートおよ配信可能な速度より早い速度でブローカにメッセージが流入しています。ブローカの遅滞は、次のどれかまたはすべてにおける制限が原因と考えられます。それは、CPU、ネットワークソケットの読み取り / 書き込み操作、ディスク読み取り / 書き込み操作、メモリーのページング、持続ストア、または JVM メモリー制限です。

> この問題の原因を確認するには

> この問題にそれ以外の原因が関与していないことを確認します。

> 問題を解決するには

> - コンピュータまたはデータストアの速度をアップグレードする
> - ブローカクラスタを使用して、多数のブローカインスタンスに負荷を分散する

> ### 問題: メッセージサーバのスループットが散発的である

> #### 現象 :

> - メッセージのスループットがときどき低下し、その後通常のパフォーマンスに戻る

> #### 考えられる原因 :

> - ブローカのメモリーリソースがかなり不足している

> 送信先とブローカに制限が適切に設定されなかったため、ブローカはメモリーが過負荷になるのを防ぐためにさらに重大なアクションを実行します。このため、メッセージのバックログがクリアされるまでは、ブローカの処理がかなり遅くなります。

> この問題の原因を確認するには

> ブローカのログで、メモリー不足の状態になっていないかどうかを確認します。[B1089]: In low memory condition, broker is attempting to free up resources に続き、メモリーの最新の状態と、使用中のメモリーの合計を示すエントリが表示されます。

> また、JVM ヒープ内の使用可能な空きメモリーも確認します。

> imqcmd metrics bkr -m cxn

> JVM メモリーの合計値が JVM メモリーの最大値に近くなると、空きメモリーは不足がちになります。

> 問題を解決するには

> - JVM を調整する (「Java 仮想マシン (JVM) の調整」を参照)
> - システムスワップスペースを増やす
> - JVM メモリーの再利用 (ガベージコレクション) を実行する

> 定期的なメモリー再利用によりシステム全体を一掃し、メモリーを開放します。これが実行されると、すべてのスレッドがブロックされます。より多くのメモリーが開放され、JVM ヒープサイズがより大きくなるほど、メモリー再利用に起因する遅延も長くなります。

> この問題の原因を確認するには

> コンピュータ上の CPU 使用率を監視します。メモリー再利用が実行されると、大幅に低下します。

> また、次のコマンド行オプションを使用してブローカを起動します。

> -vmargs -verbose:gc

> 標準出力では、メモリー再利用に要した時間が示されます。

> 問題を解決するには

> 複数の CPU を持つコンピュータでは、メモリー再利用を並行して実行するように設定します。

> -XX:+UseParallelGC=true

> - JVM は JIT コンパイラを使用してパフォーマンスを高速化させる

> この問題の原因を確認するには

> この問題にそれ以外の原因が関与していないことを確認します。

> 問題を解決するには

> しばらくの間システムを稼動させておくと、パフォーマンスは改善するはずです。

> ### 問題 : メッセージがコンシューマに到達しない

> #### 現象 :

> - プロデューサによって送信されたメッセージをコンシューマが受信しない

> #### 考えられる原因 :

> - 制限の動作が、ブローカでのメッセージの削除を引き起こしている

> 送信先メモリー内のメッセージ数またはメッセージのバイト数が設定済みの制限に達すると、ブローカはメモリーリソースを節約しようとします。これらの制限に達したときにブローカが実行する 3 つの設定可能な動作によって、メッセージが失われることがあります。

> - REMOVE_OLDEST : もっとも古いメッセージを削除する
> - REMOVE_LOW_PRIORITY : メッセージの有効期間に従いもっとも優先度の低いメッセージを削除する
> - REJECT_NEWEST : 新しいメッセージを拒否する。拒否した持続性メッセージに関する例外をスローする

> ブローカのメモリー内のメッセージ数またはメッセージのバイト数が設定済みの制限に達すると、ブローカは最新のメッセージを拒否してメモリーリソースを節約しようとします。

> この問題の原因を確認するには

> ブローカログで次のエントリを確認します。WARNING [B2011]: Storing of JMS message from...failed. このエントリには、制限を越えたことを示す別のエントリが続きます。エントリがない場合でも、メッセージが削除されたことが示されています。

> 問題を解決するには

> 制限を変更するか、動作を変更します。

> - メッセージのタイムアウトし期限切れになった

> ブローカは、タイムアウトして期限切れになったメッセージを削除します。送信先がメッセージで過分にバックログされている場合、生存期間の値が短過ぎるメッセージは削除されます。

> この問題の原因を確認するには

> ブローカログファイルで次のエントリを確認します。Expiring Messages: Expired n messages.

> 問題を解決するには

> オーバーライドを使用します。

> - 異なるコンピュータ間で時計の時間が同期化していない

> 時計が同期化されていない場合、ブローカによるメッセージの生存期間の計算がエラーとなり、メッセージが有効期限を越え、削除される場合があります。

> この問題の原因を確認するには

> すべてのコンピュータの時計を確認します。

> 問題を解決するには

> 時計を同期化します (「システムの時計の設定」を参照)。

> - コンシューミングクライアントがコネクションでのメッセージ配信の起動に失敗した

> クライアントコードがコネクションを確立し、そのコネクション上でメッセージ配信を開始するまで、メッセージは配信できません。

> この問題の原因を確認するには

> クライアントコードがコネクションを確立しメッセージ配信を開始したことを確認します。

> 問題を解決するには

> コネクションを確立しメッセージ配信を開始するように、クライアントコードをプログラミングし直します。

> ##

> パフォーマンスを改善するための設定の調整

> ### システムの調整

> 次の節では、オペレーティングシステム、JVM、および通信プロトコルで実行できる調整について説明します。

> #### Solaris での調整 : CPU 使用率、ページング / スワッピング / ディスク I/O

> オペレーティングシステムの調整については、システムのマニュアルを参照してください。

> #### Java 仮想マシン (JVM) の調整

> デフォルトでは、ブローカは 192M バイトの JVM ヒープサイズを使用します。通常、大量のメッセージ負荷がある場合はこのサイズでは小さ過ぎるため、大きくする必要があります。

> Java オブジェクトが使用する JVM のヒープ容量を使い果たしそうになると、ブローカは、フロー制御やメッセージスワップなどのさまざまな技術を使用して、メモリーを解放します。極端な状況のもとでは、メモリーを開放し、メッセージの流入を減少させるために、クライアントコネクションを閉じることもあります。このような状況を避けるため、最大 JVM ヒープ容量を十分に高く設定するようお勧めします。

> ただし、Java の最大ヒープ容量がシステムの物理メモリーに対して高くしすぎた場合、ブローカは Java ヒープ容量を増加し続け、システム全体のメモリーを使い果たしてしまうことがあります。これは、パフォーマンスの低下、予期しないブローカのクラッシュにつながり、そのシステムで実行されているほかのアプリケーションやサービスの動作にも影響を与える場合があります。一般に、オペレーティングシステムとそのほかのアプリケーションがマシンをマシン上で実行させるために十分な物理メモリーを使用させる必要があります。

> 一般に、通常時とピーク時のシステムメモリーフットプリントを評価して、十分なパフォーマンスを得られて、しかもシステムメモリーに問題を生じさせるほどではない大きさに Java ヒープサイズを設定するのがよい方法です。

> ブローカの最小ヒープサイズと最大ヒープサイズを変更するには、ブローカの起動時に -vmargs コマンド行オプションを使用します。たとえば、次のように指定します。

> /usr/bin/imqbrokerd -vmargs "-Xms256m -Xmx1024m"

> このコマンドは、起動時の 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 つのブローカプロパティを使用して修正できます。

> - imq.protocol protocol_type nodelay
> - imq.protocol protocol_type inbufsz
> - imq.protocol protocol_type outbufsz

> TCP と SSL プロトコルの場合、これらのプロパティがクライアントとブローカ間のメッセージ配信の速度に影響します。HTTP プロトコルと HTTPS プロトコルの場合は、これらのプロパティが、Web サーバ上で実行している Message Queue トンネルサーブレットとブローカ間のメッセージ配信の速度に影響します。HTTP/HTTPS プロトコルの場合、そのほかにもパフォーマンスに影響することのあるプロパティがあります (「HTTP/HTTPS の調整」を参照)。

> プロトコルを調整するためのプロパティについては、次の節で説明します。

> ##### nodelay

> nodelay プロパティは、特定のプロトコルの Nagle のアルゴリズム、つまり TCP/IP 上の TCP_NODELAY ソケットレベルのオプションの値に影響します。Nagle のアルゴリズムは、広域ネットワーク (WAN) などの低速コネクションを使用しているシステム上で TCP パフォーマンスを改善するために使用されます。

> このアルゴリズムが使用されている場合、TCP は、データをサイズの大きいパケットにバンドルすることで、複数の小さいデータの塊がリモートシステムへ送信されるのを防ぎます。ソケットに書き込まれたデータが必要なバッファサイズを満たしていない場合、プロトコルは、バッファが満たされるか、一定の遅延時間が経過するまで、パケットの送信を遅らせます。バッファがいっぱいになるか、タイムアウトが発生すると、パケットが送信されます。

> 大半のメッセージングアプリケーションでは、パケットの送信に遅延がない、つまりNagle のアルゴリズムが無効な場合にパフォーマンスは最適となります。これは、クライアントとブローカ間の大半の対話が、要求 / 応答型の対話だからです。つまり、クライアントはデータのパケットをブローカへ送信し、その応答を待ちます。たとえば、典型的な対話には次のものがあります。

> - コネクションの作成
> - プロデューサまたはコンシューマの作成
> - 持続性メッセージの送信。ブローカはメッセージの受信を確認する
> - AUTO_ACKNOWLEDGE セッションまたは CLIENT_ACKNOWLEDGE セッションでのクライアント通知の送信。ブローカは通知の処理を確認する

> これらの対話では、大半のパケットがバッファサイズより小さいサイズです。つまり、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 オプションの概要」を参照してください。

> たとえば、次のように指定します。

> imq.system.max_count=5000

> 上記で定義された値は、ブローカが未配信 / 未通知のメッセージを最大 5000 までしか保持しないことを示しています。それ以上のメッセージが送信されると、メッセージはブローカによって拒否されます。メッセージが持続的な場合は、プロデューサがメッセージを送信しようとすると例外を受け取ります。メッセージが持続的でない場合は、ブローカは暗黙のうちにメッセージを廃棄します。

> 持続性のないメッセージも持続性メッセージと同様に例外を戻すようにするには、クライアントが使用しているコネクションファクトリオブジェクトに次のプロパティを設定します。

> imqAckOnProduce = true

> 上記の設定では、クライアントは次のメッセージを送信する前に応答を待機するため、持続性のないメッセージをブローカへ送信するときのパフォーマンスを低下させることがあります。しかし、通常、ブローカでのメッセージの受信はシステムのボトルネックにならないため、この低下は許容範囲内です。

> メッセージの送信時に例外が戻った場合、クライアントは一時停止してから、送信を再試行します。

> #### 複数のコンシューマキューのパフォーマンス

> 複数のキューコンシューマがキュー送信先のメッセージを処理する効率は、設定可能なキュー送信先属性、すなわち、アクティブコンシューマの数 (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 メッセージをコンシュームしてから、次のバッチを要求します。

> 次のバッチサイズの計算方法 :

> imqConsumerFlowLimit - (現在、バッファに保留中のメッセージ数)

> そのため、imqConsumerFlowThreshold が 50% の場合、次のバッチサイズは、アプリケーションがメッセージを処理する速度に応じて 500 〜 1000 の間になります。

> imqConsumerFlowThreshold がかなり高く (100% 近くに) 設定された場合、ブローカは比較的小さいサイズのバッチを送信するため、メッセージのスループットは低下することがあります。値が低過ぎる (0% に近い) 場合は、クライアントは次のセットを配信する前に残りのバッファされたメッセージの処理を完了してしまい、メッセージスループットを低下させることがあります。一般に、特定のパフォーマンスや信頼性を考慮しない限り、imqConsumerFlowThreshold 属性のデフォルト値を変更する必要はありません。

> コンシューマベースのフロー制御、特に、imqConsumerFlowLimit は、クライアントランタイム内のメモリーを管理する最適な手段です。一般に、クライアントアプリケーションに応じて、コネクションでサポートする必要のあるコンシューマの数、メッセージのサイズ、クライアントランタイムで使用可能なメモリー総量がわかります。

> ##### コネクションベースの制限

> 一部のクライアントアプリケーションでは、エンドユーザーの選択によって、コンシューマの数が不確定が場合があります。そのような場合は、引き続き、コネクションレベルのフロー制限を使用してメモリーを管理できます。

> コネクションレベルのフロー制御は、コネクション上のすべてのコンシューマについてバッファされたメッセージの合計数を制限します。この数が imqConnectionFlowLimit を超えると、合計数がコネクションの制限を下回るまで、コネクション経由のメッセージの配信は停止します。imqConnectionFlowLimit は、imqConnectionFlowLimitEnabled プロパティを true に設定した場合にだけ使用できます。

> 1 つのセッションでキューに入るメッセージの数は、そのセッションを使用するメッセージコンシューマの数と、各コンシューマのメッセージ負荷によって決まります。クライアント側のメッセージのプロデュースまたはメッセージのコンシュームに遅延が発生する場合は、通常は、アプリケーションを再設計し、より多くのセッションにメッセージプロデューサとメッセージコンシューマを分散し、またはより多くのコネクションにセッションを分散してパフォーマンスを改善できます。

> 前へ 目次 索引 次へ

> Copyright 2003 Sun Microsystems, Inc. All rights reserved.