WebSphere Message Broker バージョン 8.0.0.5 オペレーティング・システム: AIX、HP-Itanium、Linux、Solaris、Windows、z/OS

製品の最新バージョンについては、IBM Integration Bus バージョン 9.0 をご覧ください。

WebSphere Message Broker Explorer でのリソース統計データの表示

WebSphere® Message Broker Explorer を使用して、「ブローカー・リソース」ビューと「ブローカー・リソース・グラフ」ビューで実行グループのリソース統計データを表示します。

始める前に:

統計がパブリッシュされるトピックにサブスクライブすることによってリソース統計の収集データを表示することもできます。 詳細については、統計レポートへのサブスクライブを参照してください。

WebSphere Message Broker Explorer でリソース統計を表示するには、以下の手順を実行します。

  1. 「WebSphere MQ Explorer - ナビゲーター」ビューで、「ブローカー」フォルダーを展開します。
  2. 「リソース統計」ビューおよび「リソース統計グラフ」ビューを開くには、「ウィンドウ」 > 「ビューの表示」 > 「リソース統計」をクリックします。 この 2 つのビューは一緒に表示されます。 一方のビューを閉じると、もう一方のビューも閉じます。
  3. これらのビューの情報に基づいて、統計が使用可能なリソースの使用状況を検討します。
    以下の例では、リソース統計を収集することによって答えることができる質問のタイプを示します。 このリストは、すべてを網羅しておらず、リソース・タイプもすべては含まれていません。 リソース・タイプ全体のリスト、およびそれぞれに対して収集される情報のタイプについては、リソース統計データを参照してください。
    JVM の統計
    JVM はどれほどのメモリーを使用しているか?

    オペレーティング・システムの固有のツールの中には、実行グループが使用しているメモリーの合計量を確認できるツールも多くありますが、それらのツールで、実行グループの Java™ の処理とそれ以外の処理を切り分けてメモリーの使用量を確認することはできません。 CommittedMemoryInMB フィールドを調べることにより、JVM に現在割り振られているメモリーの量を確認できます。 さらに、MaxMemoryInMB フィールドを調べると、割り振ることができるメモリーの最大量を確認できます。

    ガーベッジ・コレクションはどれほどの頻度で発生しているか? それが実行グループのパフォーマンスに影響しているか?

    JVM でガーベッジ・コレクションが発生している頻度を確認するには、CumulativeNumberOfGCCollections フィールドを調べて、コレクションの発生率が上がっているかどうかを検証できます。 ガーベッジ・コレクションは通常のプロセスであり、ある程度は予期しておく必要があります。 ただし、ガーベッジ・コレクションが過剰になると、パフォーマンスに影響を与える可能性があります。

    現在のガーベッジ・コレクションが過剰かどうかを確認するには、CumulativeGCTimeInSeconds の値をモニターします。 この値が 20 秒の各統計間隔で増加の幅が 2 秒を超えている場合は、mqsichangeproperties コマンドを使用して、実行グループの JVM の最大ヒープ・サイズを大きくしてみてください。 さらに、デプロイ済みのメッセージ・フローに組み込まれているすべての Java ユーザー定義ノードと JavaCompute ノードを調べて、再利用できるオブジェクトを多数作成しては削除するという状況がないかどうかを確認することもできます。頻繁な削除処理によって、ガーベッジ・コレクションが過剰に発生することがあるからです。

    最小ヒープ・サイズまたは最大ヒープ・サイズを変更する必要があるか?
    • 20 秒の各統計間隔で CumulativeGCTimeInSeconds の値の増加の幅が 2 秒を超えている場合は、最大ヒープ・サイズを大きくして、その増加の幅を減らします。
    • UsedMemoryInMB の値が InitialMemoryInMB の値に近づくことがない場合は、ヒープのメモリーを必要以上に割り振っている可能性があります。 その場合には実行グループの JVM の最小ヒープ・サイズの値を小さくして、UsedMemoryInMB の値に近くなるように値を設定します。

    これらの値を少しずつ変更して結果を確認していくことにより、それぞれの環境で最適な設定値を判別できます。

    パーサー
    メッセージ・パーサーが予想よりも多くのメモリーを使用していないか?

    メッセージ・フローは、入力メッセージを解析し、多くの出力メッセージを作成できます。 これらのメッセージのビット・ストリームやメッセージ・ツリーは大容量になっている可能性があります。 このメッセージ処理を実行するために作成されたパーサーがかなりのメモリー量を消費していることが考えられます。 パーサー統計を使用してメッセージ・フロー・パーサーが予想よりも多くのメモリーを使用していないか判別してください。 多くのメモリーを消費している場合は、そのようなフローを別個の実行グループにデプロイするか、ESQL または Java プラグイン API 処理を改善して大規模なメッセージや変換を効率的に処理することを考慮するようにしてください。

    特定のメッセージ・フローでメッセージの構文解析、または書き込みが頻繁に失敗していないか?

    メッセージ・フローが無効なメッセージを受け取る、または書き込もうとしている場合、これはパーサーによって拒否される可能性があります。 メッセージ・パーサー統計を使用して、メッセージ・フローが、正常な処理と比較して大量の入力または出力メッセージを拒否しているかどうかを確認してください。

    アウトバウンド・ソケット
    各ノードはアウトバウンド・ソケットを再利用しているか?

    アウトバウンド・ソケットの作成は、コスト高の操作になる可能性があります。コンピューターで使用できるソケットの数には限りがあります (つまり、ソケットは有限のリソースです)。 このため、ソケットの再利用を促進すると、パフォーマンスが向上する場合があります。 ワークロードが連続的で一貫した状態であれば、初期の期間のアクティビティーの後に実行グループがソケットの再利用を開始すると、TotalSockets の値は小さくなります。

    TotalSockets の値は、時間が経過するにつれて少しずつ大きくなっていくと予想されます。非アクティブの状態が一定期間続いた後、またはソケットの利用回数が多くなった時に、ソケットは閉じられるからです。

    時間が経過するにつれて、TotalSockets の値に大幅な上昇傾向が見られる場合は、アウトバウンド・ソケットが再利用されていない可能性があります。

    メッセージ・フローに HTTPRequest ノードが含まれている場合は、キープアライブ・プロパティー「HTTP/1.1 キープアライブを使用可能にする」が設定されていることを確認してください。

    さらに、呼び出し対象のエンドポイントがキープアライブ・ソケットを使用しているかどうかも確認してください。

    使用頻度が高いのはどのエンドポイントか?

    TotalMessages の値によって、各エンドポイントが使用中になる頻度を確認できます。 要約レコードの値では、実行グループ全体で発生しているアクティビティーの量を確認できます。

    送受信するメッセージはどれほどの大きさか?

    SentMessageSize_* フィールドと ReceivedMessageSize_* フィールドの値によって、各エンドポイントの間を流れるメッセージのサイズを確認できます。

    JDBC 接続プール
    接続プールのサイズを変更する必要があるか?

    接続待ちの呼び出し元の数が多く、待ち時間が増えていることを統計で確認できる場合は、JDBCProvider 構成可能サービスの MaxConnectionPoolSize プロパティーを使用して、プールのサイズを大きくすることを検討してください。

    あるいは、メッセージ・フローで構成されている追加インスタンスの数を減らしてみることもできます。

    TCPIPClientNodes
    各ノードはアウトバウンド・ソケットを再利用しているか?

    アウトバウンド・ソケットの作成は、コスト高の操作になる可能性があります。コンピューターで使用できるソケットの数には限りがあります (つまり、ソケットは有限のリソースです)。 このため、ソケットの再利用を促進すると、パフォーマンスが向上する場合があります。 ワークロードが連続的で一貫した状態であれば、初期の期間のアクティビティーの後に実行グループがソケットの再利用を開始すると、TotalSockets の値は小さくなります。

    TotalSockets の値は、時間が経過するにつれて少しずつ大きくなっていくと予想されます。非アクティブの状態が一定期間続いた後、またはソケットの利用回数が多くなった時に、ソケットは閉じられるからです。

    時間が経過するにつれて、TotalSockets の値に大幅な上昇傾向が見られる場合は、アウトバウンド・ソケットが再利用されていない可能性があります。

    メッセージ・フローに HTTPRequest ノードが含まれている場合は、キープアライブ・プロパティー「HTTP/1.1 キープアライブを使用可能にする」が設定されていることを確認してください。

    さらに、呼び出し対象のエンドポイントがキープアライブ・ソケットを使用しているかどうかも確認してください。

    WebSphere Message Broker Explorer に表示される情報は、TCP/IP フローとどのような関係にあるか?
    エントリーは、フローごとではなく構成可能なサービスごとに表示されます。
特記事項 | 商標 | ダウンロード | ライブラリー | サポート | フィードバック

Copyright IBM Corporation 1999, 2014Copyright IBM Corporation 1999, 2014.

        
        最終更新:
        
        最終更新: 2015-02-28 17:49:15


タスク・トピックタスク・トピック | バージョン 8.0.0.5 | bj43370_