test

Sun Java System Message Queue 3.7 UR1 管理ガイド

システムの調整

次の節では、オペレーティングシステム、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 バイトに設定します。

どのような場合でも、ブローカのログファイルを確認するか、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 のアルゴリズムが使用されている場合は、ブローカは数ミリ秒遅れて、コンシューマに応答を送信します。

ただし、Nagle のアルゴリズムは、接続が低速でブローカの応答が必要ない状況で、パフォーマンスを改善することができます。これは、クライアントが持続性のないメッセージを送信する場合や、クライアント通知がブローカによって確認されない場合 (DUPS_OK_ACKNOWLEDGE セッション) です。

inbufsz/outbufsz

inbufsz プロパティーは、ソケットからのデータを読み取る入力ストリームのバッファーサイズを設定します。同様に、outbufsz は、ブローカがデータをソケットに書き込むために使用する出力ストリームのバッファーサイズを設定します。

一般に、どちらのパラメータも受信パケットまたは送信パケットの平均サイズより多少大きい値に設定する必要があります。経験上、これらのプロパティーはパケットの平均サイズに 1K バイトを足した値 (K バイト単位で四捨五入) に設定すると良いでしょう。たとえば、本文が 1K バイトのパケットをブローカで受信している場合、パケット全体のサイズ (メッセージ本文 + ヘッダー + プロパティー) は約 1200 バイトです。inbufsz を 2K バイト (2048 バイト) にすると、妥当なパフォーマンスが得られます。inbufsz または 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 サーバーのリソースを節約できます。

ファイルベースの持続ストアの調整

ファイルベースの持続ストアの調整については、「持続サービス」を参照してください。