WebSphere® Message Broker Explorer を使用して、「ブローカー・リソース」ビューと「ブローカー・リソース・グラフ」ビューで実行グループのリソース統計データを表示します。
統計がパブリッシュされるトピックにサブスクライブすることによってリソース統計の収集データを表示することもできます。 詳細については、統計レポートへのサブスクライブを参照してください。
WebSphere Message Broker Explorer でリソース統計を表示するには、以下の手順を実行します。
オペレーティング・システムの固有のツールの中には、実行グループが使用しているメモリーの合計量を確認できるツールも多くありますが、それらのツールで、実行グループの Java™ の処理とそれ以外の処理を切り分けてメモリーの使用量を確認することはできません。 CommittedMemoryInMB フィールドを調べることにより、JVM に現在割り振られているメモリーの量を確認できます。 さらに、MaxMemoryInMB フィールドを調べると、割り振ることができるメモリーの最大量を確認できます。
JVM でガーベッジ・コレクションが発生している頻度を確認するには、CumulativeNumberOfGCCollections フィールドを調べて、コレクションの発生率が上がっているかどうかを検証できます。 ガーベッジ・コレクションは通常のプロセスであり、ある程度は予期しておく必要があります。 ただし、ガーベッジ・コレクションが過剰になると、パフォーマンスに影響を与える可能性があります。
現在のガーベッジ・コレクションが過剰かどうかを確認するには、CumulativeGCTimeInSeconds の値をモニターします。 この値が 20 秒の各統計間隔で増加の幅が 2 秒を超えている場合は、mqsichangeproperties コマンドを使用して、実行グループの JVM の最大ヒープ・サイズを大きくしてみてください。 さらに、デプロイ済みのメッセージ・フローに組み込まれているすべての Java ユーザー定義ノードと JavaCompute ノードを調べて、再利用できるオブジェクトを多数作成しては削除するという状況がないかどうかを確認することもできます。頻繁な削除処理によって、ガーベッジ・コレクションが過剰に発生することがあるからです。
これらの値を少しずつ変更して結果を確認していくことにより、それぞれの環境で最適な設定値を判別できます。
メッセージ・フローは、入力メッセージを解析し、多くの出力メッセージを作成できます。 これらのメッセージのビット・ストリームやメッセージ・ツリーは大容量になっている可能性があります。 このメッセージ処理を実行するために作成されたパーサーがかなりのメモリー量を消費していることが考えられます。 パーサー統計を使用してメッセージ・フロー・パーサーが予想よりも多くのメモリーを使用していないか判別してください。 多くのメモリーを消費している場合は、そのようなフローを別個の実行グループにデプロイするか、ESQL または Java プラグイン API 処理を改善して大規模なメッセージや変換を効率的に処理することを考慮するようにしてください。
メッセージ・フローが無効なメッセージを受け取る、または書き込もうとしている場合、これはパーサーによって拒否される可能性があります。 メッセージ・パーサー統計を使用して、メッセージ・フローが、正常な処理と比較して大量の入力または出力メッセージを拒否しているかどうかを確認してください。
アウトバウンド・ソケットの作成は、コスト高の操作になる可能性があります。コンピューターで使用できるソケットの数には限りがあります (つまり、ソケットは有限のリソースです)。 このため、ソケットの再利用を促進すると、パフォーマンスが向上する場合があります。 ワークロードが連続的で一貫した状態であれば、初期の期間のアクティビティーの後に実行グループがソケットの再利用を開始すると、TotalSockets の値は小さくなります。
TotalSockets の値は、時間が経過するにつれて少しずつ大きくなっていくと予想されます。非アクティブの状態が一定期間続いた後、またはソケットの利用回数が多くなった時に、ソケットは閉じられるからです。
時間が経過するにつれて、TotalSockets の値に大幅な上昇傾向が見られる場合は、アウトバウンド・ソケットが再利用されていない可能性があります。
メッセージ・フローに HTTPRequest ノードが含まれている場合は、キープアライブ・プロパティー「HTTP/1.1 キープアライブを使用可能にする」が設定されていることを確認してください。
さらに、呼び出し対象のエンドポイントがキープアライブ・ソケットを使用しているかどうかも確認してください。
TotalMessages の値によって、各エンドポイントが使用中になる頻度を確認できます。 要約レコードの値では、実行グループ全体で発生しているアクティビティーの量を確認できます。
SentMessageSize_* フィールドと ReceivedMessageSize_* フィールドの値によって、各エンドポイントの間を流れるメッセージのサイズを確認できます。
接続待ちの呼び出し元の数が多く、待ち時間が増えていることを統計で確認できる場合は、JDBCProvider 構成可能サービスの MaxConnectionPoolSize プロパティーを使用して、プールのサイズを大きくすることを検討してください。
あるいは、メッセージ・フローで構成されている追加インスタンスの数を減らしてみることもできます。
アウトバウンド・ソケットの作成は、コスト高の操作になる可能性があります。コンピューターで使用できるソケットの数には限りがあります (つまり、ソケットは有限のリソースです)。 このため、ソケットの再利用を促進すると、パフォーマンスが向上する場合があります。 ワークロードが連続的で一貫した状態であれば、初期の期間のアクティビティーの後に実行グループがソケットの再利用を開始すると、TotalSockets の値は小さくなります。
TotalSockets の値は、時間が経過するにつれて少しずつ大きくなっていくと予想されます。非アクティブの状態が一定期間続いた後、またはソケットの利用回数が多くなった時に、ソケットは閉じられるからです。
時間が経過するにつれて、TotalSockets の値に大幅な上昇傾向が見られる場合は、アウトバウンド・ソケットが再利用されていない可能性があります。
メッセージ・フローに HTTPRequest ノードが含まれている場合は、キープアライブ・プロパティー「HTTP/1.1 キープアライブを使用可能にする」が設定されていることを確認してください。
さらに、呼び出し対象のエンドポイントがキープアライブ・ソケットを使用しているかどうかも確認してください。