この章の内容は次のとおりです。
Coherenceデータグラム・テスト・ユーティリティは、複数のコンピュータ間のネットワーク・パフォーマンスをテストしてチューニングするために使用します。このユーティリティにより、Coherenceクラスタ管理通信に対応するようネットワークが最適に構成されます。テストには次の2種類があります。サーバーのペアのパフォーマンスをテストすることにより、それらが正しく構成されているかどうかを確認するポイント・ツー・ポイント・テストと、ネットワーク自体が正しく機能しているかどうかを確認する分散データグラム・テストです。どちらのテストの実行にも成功する必要があります。
データグラム・テストは、3種類のモード(パケット・パブリッシャまたはパケット・リスナー、あるいはその両方)のいずれかで動作します。このユーティリティを実行すると、パブリッシャがパケットをリスナーに送信し、そのリスナーがスループットや成功率などの統計を測定します。このテストの結果に基づいて環境をチューニングして、最大のパフォーマンスを実現します。パフォーマンス・チューニングを参照してください。
この項には次のトピックが含まれます:
データグラム・テスト・ユーティリティを実行するには、コマンド行からcom.tangosol.net.DatagramTest
クラスを使用するか、COHERENCE_HOME
/bin
ディレクトリにあるdatagram-test
スクリプトを実行します。スクリプトは、WindowsベースのプラットフォームとUNIXベースのプラットフォームの両方に用意されています。
次の例は、DatagramTest
クラスの使用方法を示しています。
java -server -cp coherence.jar com.tangosol.net.DatagramTest <command value> <command value> ...
次の例は、スクリプトの使用方法を示しています。
datagram-test <command value> <command value> ...
表2-1では、データグラム・テスト・ユーティリティで利用できるコマンド行オプションについて説明しています。
表2-1 データグラム・テスト・ユーティリティのコマンド行オプション
コマンド | 必須/オプション | 適用範囲 | 説明 | デフォルト値 |
---|---|---|---|---|
-local |
オプション |
両方 |
バインド先のローカル・アドレス、 |
localhost:9999 |
-packetSize |
オプション |
両方 |
作業対象パケットのサイズ、バイト単位で指定 |
1468 |
-payload |
オプション |
両方 |
各パケットに含めるデータ量パケット・サイズを一致させるには、 |
0 |
-processBytes |
オプション |
両方 |
処理対象の各パケットのバイト数(4の倍数) |
4 |
-rxBufferSize |
オプション |
リスナー |
受信バッファのサイズ、パケット単位で指定 |
1428 |
-rxTimeoutMs |
オプション |
リスナー |
接続が閉じられるまでの非アクティブ時間 |
1000 |
-txBufferSize |
オプション |
パブリッシャ |
送信バッファのサイズ、パケット単位で指定 |
16 |
-txRate |
オプション |
パブリッシャ |
データ送信の速度、メガバイト単位で指定 |
unlimited |
-txIterations |
オプション |
パブリッシャ |
終了前に公開するパケット数を指定 |
unlimited |
-txDurationMs |
オプション |
パブリッシャ |
終了前に公開する期間を指定 |
unlimited |
-reportInterval |
オプション |
両方 |
レポートを出力する間隔、パケット単位で指定 |
100000 |
-tickInterval |
オプション |
両方 |
ティック・マークを出力する間隔 |
1000 |
-log |
オプション |
リスナー |
測定したパフォーマンスの表形式レポートを保存するファイルの名前 |
なし |
-logInterval |
オプション |
リスナー |
ログに測定結果を出力する間隔 |
100000 |
-polite |
オプション |
パブリッシャ |
パブリッシャが公開を実行する前に、リスナーの接続を待つかどうかを示すスイッチ |
off |
-provider |
オプション |
両方 |
使用するソケット・プロバイダ( |
system |
引数 |
オプション |
パブリッシャ |
空白で区切られた公開先アドレスのリスト、 |
なし |
この項には、ポイント・ツー・ポイント・データグラム・テストと分散データグラム・テストを実行するための手順が含まれます。どちらのテストの実行にも成功する必要があり、その際に重大なパフォーマンスの問題やパケットの損失が発生していないことも示す必要があります。データグラム・レポート統計の理解を参照してください。
この項には次のトピックが含まれます:
この項の例では、サーバーA (IPアドレス195.0.0.1
)と、サーバーB (IPアドレス195.0.0.2
)という2つのサーバー間のネットワーク・パフォーマンスのテスト方法を示します。一方のサーバーはパケット・パブリッシャとして動作し、もう一方はパケット・リスナーとして動作します。パブリッシャは可能なかぎり高速にパケットを送信し、リスナーはパフォーマンス統計を測定して報告します。
まず、サーバーA上のリスナーを起動します。次に例を示します。
datagram-test.sh
[ENTER]を押すと、ユーティリティは、パケット受信の準備が完了していることを示します。例2-1にサンプル出力を示します。
例2-1 リスナーの起動からの出力
starting listener: at /195.0.0.1:9999 packet size: 1468 bytes buffer size: 1428 packets report on: 100000 packets, 139 MBs process: 4 bytes/packet log: null log on: 139 MBs
デフォルトでは、このテストにより、1428個のパケット(約2MB)を十分に保持できるネットワーク受信バッファの割当てが試行されます。このバッファの割当てができない場合、ユーティリティはエラーを報告して終了します。-rxBufferSize
パラメータを使用して要求するバッファのサイズを小さくするか、オペレーティング・システムのネットワーク・バッファの設定を大きくしてください。オペレーティング・システムのバッファを大きくすると、最適なパフォーマンスが得られます。本番チェックリストを参照してください。
サーバーBでパブリッシャを起動して、サーバーAに向けてパブリッシュします。次に例を示します。
datagram-test.sh servera
[ENTER]を押すと、Server Bのテスト・インスタンスによってリスナーとパブリッシャの両方が起動されます。ただし、この構成ではリスナーは使用しません。例2-2は、Server Bのコマンド・ウィンドウに表示されるサンプル出力を示しています。
例2-2 データグラム・テスト: サーバーでのリスナーとパブリッシャの起動
starting listener: at /195.0.0.2:9999 packet size: 1468 bytes buffer size: 1428 packets report on: 100000 packets, 139 MBs process: 4 bytes/packet log: null log on: 139 MBs starting publisher: at /195.0.0.2:9999 sending to servera/195.0.0.1:9999 packet size: 1468 bytes buffer size: 16 packets report on: 100000 packets, 139 MBs process: 4 bytes/packet peers: 1 rate: no limit no packet burst limit oooooooooOoooooooooOoooooooooOoooooooooOoooooooooOoooooooooOoooooooooOoooooooooO
データがネットワーク上に出力(Output)されると、一連のo
とO
のマークが表示されます。o
はそれぞれ1000パケットを表し、10,000パケットごとにO
のインジケータが表示されます。
サーバーAでは、これに対応してネットワーク入力(Input)を表すi
とI
のマークのセットが表示されます。これは、2つのテスト・インスタンスが通信していることを示します。
ポイント・ツー・ポイント・テストは、双方向モードで実行することもできます。このモードでは、サーバーがパブリッシャとリスナーとして動作します。ポイント・ツー・ポイント・テストで使用したのと同じテスト・インスタンスを使用して、サーバーAのインスタンスにサーバーBのアドレスを指定します。たとえば、サーバーAで次のコマンドを実行します。
datagram-test.sh -polite serverb
-polite
パラメータを使用して、このテスト・インスタンスに対し、データの受信を開始するまでパブリッシュを開始しないように指示します。前述の同じコマンドをサーバーBで実行します。
datagram-test.sh servera
分散テストは、3台以上のコンピュータのパフォーマンスをテストするために使用します。たとえば、1つのリスナーをターゲットにするように、2つのパブリッシャを設定できます。このスタイルのテストは単純な1対1のテストと比較してはるかに現実的で、他の方法では確認できないネットワークのボトルネックを特定できる場合があります。
次の例では、4台のコンピュータ間でダイアグラム・テストを実行します。
サーバーA上:
datagramtest.sh -txRate 100 -polite serverb serverc serverd
サーバーB上:
datagramtest.sh -txRate 100 -polite servera serverc serverd
Server C上:
datagramtest.sh -txRate 100 -polite servera serverb serverd
サーバーD上:
datagramtest.sh -txRate 100 servera serverb serverc
このテスト・シーケンスでは、すべてのノードは他のすべてのノードに、1秒当たりで合計100MBを送信します(1ノード当たり33MB/秒に相当)。完全にスイッチが設定された1GbEネットワークでは、パケットを失うことなくこれを達成できる必要があります。
テストの実行を簡略化するために、すべてのノードは同一のターゲット・リストを使用して起動できます。自分自身への送信も行われますが、このループバック・データは容易に除外できます。最後のノードが起動されるまで他のすべてのノードが遅延するため、最後のノードを除くすべてのノードは、-polite
スイッチを使用して起動することが重要です。
テストのそれぞれの側(パブリッシャとリスナー)から定期的にパフォーマンス統計がレポートされます。パブリッシャでは、ネットワーク上にデータを公開する速度のみがレポートされます。次に例を示します。
Tx summary 1 peers: life: 97 MB/sec, 69642 packets/sec now: 98 MB/sec, 69735 packets/sec
このレポートには、現在の送信速度(前回のレポート以降)と存続期間の送信速度の両方が記載されます。
表2-2は、リスナーでレポートできる統計について説明しています。
表2-2 リスナーの統計
項目 | 説明 |
---|---|
Elapsed |
レポート対象の時間間隔 |
Packet size |
受信したパケットのサイズ |
Throughput |
パケットの受信速度 |
Received |
受信したパケット数 |
Missing |
失われていることが検出されたパケットの数 |
Success rate |
合計送信パケット数に対する受信パケット数の割合 |
Out of order |
着信順序が乱れているパケットの数 |
Average offset |
パケットの着信順序の乱れの程度を示すインジケータ |
パブリッシャの場合と同様、現在と存続期間の両方の統計がレポートされます。次の例は、一般的なリスナーのレポートを示しています。
Lifetime: Rx from publisher: /195.0.0.2:9999 elapsed: 8770ms packet size: 1468 throughput: 96 MB/sec 68415 packets/sec received: 600000 of 611400 missing: 11400 success rate: 0.9813543 out of order: 2 avg offset: 1 Now: Rx from publisher: /195.0.0.2:9999 elapsed: 1431ms packet size: 1468 throughput: 98 MB/sec 69881 packets/sec received: 100000 of 100000 missing: 0 success rate: 1.0 out of order: 0 avg offset: 0
特に重要な項目は、throughputとsuccess rateです。目標は、success rateを可能なかぎり1.0近くに維持しながら、最高のthroughputを見つけることです。100Mbネットワークの設定では、約10MB/秒の速度を達成する必要があります。1Gbネットワークの設定では、約100MB/秒の速度を達成する必要があります。これらの速度を実現するには、なんらかの速度調整が必要になります。ネットワークがこれらの速度を達成できない場合、または速度がかなり低い場合、ネットワーク構成の問題がある可能性が非常に高いです。ネットワークのチューニングを参照してください。
速度調整
-txRate M
パラメータを組み込むことによって、テストのパブリッシャ側で、MB/秒単位のデータ速度を指定して速度を調整できます。M
は、テストでネットワークに設定される最大MB/秒を表します。
Coherenceメッセージ・バス・テスト・ユーティリティは、メッセージ・バスの実装のパフォーマンス特性とそれらが動作するネットワークのテストに使用します。このユーティリティにより、クラスタ・データ・サービス間の通信に対応するようネットワークが最適に構成されます。具体的には、このユーティリティを使用して、Exalogic以外のシステムに対するデフォルト・トランスポートであるTCPメッセージ・バス(TMB)の実装と、Exalogicシステムに対するデフォルト・トランスポートであるインフィニバンド・メッセージ・バス(IMB)の実装をテストできます。このテストの結果に基づいて環境をチューニングすることで、最大のパフォーマンスを実現します。TCPに関する考慮事項を参照してください。
この項には次のトピックが含まれます:
メッセージ・バス・テスト・ユーティリティを実行するには、コマンドラインからcom.oracle.common.net.exabus.util.MessageBusTest
クラスを使用します。次の例は、MessageBusTest
クラスの使用方法を示しています。
java -server -cp coherence.jar com.oracle.common.net.exabus.util.MessageBusTest <command value> <command value> ...
表2-3では、メッセージ・バス・テスト・ユーティリティで使用できるコマンドライン・オプションについて説明しています。
表2-3 メッセージ・バス・テスト・ユーティリティのコマンドライン・オプション
コマンド | 必須/オプション | 説明 | デフォルト値 |
---|---|---|---|
-bind |
必須 |
作成する1つ以上のローカル・エンド・ポイントのリスト |
なし |
-peer |
必須 |
送信先となる1つ以上のリモート・エンド・ポイントのリスト |
なし |
-rxThreads |
オプション |
バウンド・エンドポイント(リエントラント不可)ごとの受信スレッド数 |
|
-txThreads |
オプション |
バウンド・エンドポイントごとの送信スレッド数 |
|
-msgSize |
オプション |
送信するメッセージ・サイズの範囲で、 |
4096 |
-chunkSize |
オプション |
1単位として処理するバイト数を定義します。つまり、byteの場合は1、longの場合は8で、0 (ゼロ)を指定すると無効になります |
|
-cached |
オプション |
可能であればメッセージ・オブジェクトを再利用して、バッファ・マネージャのオーバーヘッドを軽減します |
|
-txRate |
オプション |
ターゲットのアウトバウンド・データ率(Mbps) |
|
-txMaxBacklog |
オプション |
テストで送信スレッドごとに生成される最大バックログ。 |
|
-rxRate |
オプション |
ターゲットのインバウンド・データ率(Mbps) |
|
-flushFreq |
オプション |
フラッシュ前に送信するメッセージ数、または自動の場合は0 |
0 |
-latencyFreq |
オプション |
待機時間のサンプリングまでに送信するメッセージ数 |
100 |
-noReceipts |
オプション |
指定した場合は受信を使用せず、GCにメッセージの再利用を任せます |
false |
-manager |
オプション |
使用するバッファ・マネージャ(net、directまたはheap) |
net |
-depotFactory |
オプション |
|
|
-reportInterval |
オプション |
レポートの間隔 |
5秒 |
-polite |
オプション |
指定した場合、このインスタンスは接続するまで送信を開始しません |
|
-block |
オプション |
指定した場合、レスポンスの待機中、送信スレッドでブロックされます |
false |
-relay |
オプション |
指定した場合、受信されたメッセージはピアの1つにリレーされます |
false |
-ignoreFlowControl |
オプション |
指定した場合、フロー・コントロール・イベントは無視されます。フロー・コントロール・イベントを無視する場合は、 |
false |
-poll |
オプション |
指定した場合、 |
|
-prompt |
オプション |
指定した場合、各送信前にユーザーにプロンプトが表示されます |
|
-tabular |
オプション |
指定した場合、出力に表形式が使用されます |
|
-warmup |
オプション |
ウォームアップのために廃棄される期間またはメッセージ数 |
0 |
-verbose |
オプション |
指定した場合、詳細デバッグ出力が可能になります |
この項では、TMBトランスポートに対するポイント・ツー・ポイント・メッセージ・バス・テストおよび分散メッセージ・バス・テストの実行手順を説明します。どちらのテストの実行にも成功する必要があり、その際に重大なパフォーマンスの問題やエラーが発生していないことも示す必要があります。
この項には次のトピックが含まれます:
この項の例では、サーバーA (IPアドレス195.0.0.1
)と、サーバーB (IPアドレス195.0.0.2
)という2つのサーバー間のネットワーク・パフォーマンスのテスト方法を示します。サーバーAはサーバーとして動作し、サーバーBはクライアントとして動作します。
まず、サーバーA上のリスナーを起動します。次に例を示します。
java -cp coherence.jar com.oracle.common.net.exabus.util.MessageBusTest -bind tmb://servera:8000
[ENTER]を押すと、ユーティリティは、メッセージ受信の準備が完了していることを示します。例2-3にサンプル出力を示します。
例2-3 サーバー・リスナーの起動からの出力
OPEN event for tmb://195.0.0.1:8000
サーバーBでクライアントを起動し、サーバーAにメッセージを送信させます。次に例を示します。
java -cp coherence.jar com.oracle.common.net.exabus.util.MessageBusTest -bind tmb://serverb:8000 -peer tmb://servera:8000
サーバーBのテスト・インスタンスによってクライアントとサーバー・リスナーの両方が起動されます。メッセージ・バス・テストは、常に双方向通信を実行します。デフォルト・モードでは、クライアントはサーバーにメッセージを絶え間なく送信し、サーバーは定期的にクライアントに応答します。この構成では、通信の大部分がクライアントからサーバーへのものであるのに対し、サーバーからクライアントへの通信は頻度が低いので待機時間の測定を考慮に入れます。例2-4は、Server Bのコマンド・ウィンドウに表示されるサンプル出力を示しています。
注意:
例2-4のパフォーマンス結果は、ご使用のネットワーク環境を示していない可能性もあります。
例2-4 メッセージ・バス・テスト — クライアントおよびサーバーの起動
OPEN event for tmb://195.0.0.2:8001 CONNECT event for tmb://195.0.0.1:8000 on tmb://195.0.0.2:8001 now: throughput(out 65426msg/s 2.14gb/s, in 654msg/s 21.4mb/s), latency(response(avg 810.71us, effective 1.40ms, min 37 .89us, max 19.59ms), receipt 809.61us), backlog(out 42% 1556/s 48KB, in 0% 0/s 0B), connections 1, errors 0 life: throughput(out 59431msg/s 1.94gb/s, in 594msg/s 19.4mb/s), latency(response(avg 2.12ms, effective 3.85ms, min 36.32us, max 457.25ms), receipt 2.12ms), backlog(out 45% 1497/s 449KB, in 0% 0/s 0B), connections 1, errors 0
デフォルトのテストでは、最大帯域幅を使用して最大量のメッセージのプッシュを試行しますが、待機時間が長くなります。-block
コマンドを使用し、データのストリーミングをリクエストとレスポンスで切り替えてテストすると、ネットワークの最小待機時間の改善が示されます。
now: throughput(out 17819msg/s 583mb/s, in 17820msg/s 583mb/s), latency(response(avg 51.06us, effective 51.06us, min 43.42us, max 143.68us), receipt 53.36us), backlog(out 0% 0/s 0B, in 0% 0/s 0B), connections 1, errors 0 life: throughput(out 16635msg/s 545mb/s, in 16635msg/s 545mb/s), latency(response(avg 56.49us, effective 56.49us, min 43.03us, max 13.91ms), receipt 59.43us), backlog(out 0% 0/s 2.18KB, in 0% 0/s 744B), connections 1, errors 0
ポイント・ツー・ポイント・テストは、双方向モードで実行することもできます。このモードでは、サーバーがクライアントとサーバーの両方として動作します。ポイント・ツー・ポイント・テストで使用したのと同じテスト・インスタンスを使用します。たとえば、サーバーAで次のコマンドを実行します。
java -cp coherence.jar com.oracle.common.net.exabus.util.MessageBusTest -bind tmb://servera:8000 -peer tmb://serverb:8000 -polite
-polite
パラメータを使用して、このテスト・インスタンスに対し、データの受信を開始するまでパブリッシュを開始しないように指示します。サーバーBで次を実行します。
java -cp coherence.jar com.oracle.common.net.exabus.util.MessageBusTest -bind tmb://serverb:8000 -peer tmb://servera:8000
分散テストは、3台以上のコンピュータのパフォーマンスをテストするために使用します。このスタイルのテストは単純な1対1のテストと比較してはるかに現実的で、他の方法では確認できないネットワークのボトルネックを特定できる場合があります。
次の例では、4台のコンピュータ間で双方向メッセージ・バス・テストを実行します。
サーバーA上:
java -cp coherence.jar com.oracle.common.net.exabus.util.MessageBusTest -bind tmb://servera:8000 -peer tmb://serverb:8000 tmb://serverc:8000 tmb://serverd:8000 -polite
サーバーB上:
java -cp coherence.jar com.oracle.common.net.exabus.util.MessageBusTest -bind tmb://serverb:8000 -peer tmb://servera:8000 tmb://serverc:8000 tmb://serverd:8000 -polite
Server C上:
java -cp coherence.jar com.oracle.common.net.exabus.util.MessageBusTest -bind tmb://serverc:8000 -peer tmb://servera:8000 tmb://serverb:8000 tmb://serverd:8000 -polite
サーバーD上:
java -cp coherence.jar com.oracle.common.net.exabus.util.MessageBusTest -bind tmb://serverd:8000 -peer tmb://servera:8000 tmb://serverb:8000 tmb://serverc:8000 -polite
最後のノードが起動されるまで他のすべてのノードが遅延するため、最後のノードを除くすべてのノードは、-polite
スイッチを使用して起動することが重要です。
メッセージ・バス・テストのそれぞれの側(クライアントとサーバー)から定期的にパフォーマンス統計がレポートされます。出力例は、リクエストを送信しているクライアントからのものです。
throughput(out 17819msg/s 583mb/s, in 17820msg/s 583mb/s), latency(response(avg 51.06us, effective 51.06us, min 43.42us, max 143.68us), receipt 53.36us), backlog(out 0% 0/s 0B, in 0% 0/s 0B), connections 1, errors 0
レポートには、前回のレポート以降の統計(now:
)と集計した存続期間の統計(life:
)の両方が出力されます。
表2-2では、メッセージ・バス統計について説明します。
表2-4 メッセージ・バスの統計
項目 | 説明 |
---|---|
throughput |
送受信される1秒当たりのメッセージ量と送信率 |
latency |
メッセージの応答および受信にかかった時間 |
backlog |
送信および処理を待機中のメッセージ数 |
connections |
メッセージ・リスナー間のオープン接続数 |
errors |
失われていることが検出されたメッセージの数。 |
特に重要な項目は、throughputとlatencyです。目標は、待機時間が長くにならず、可能なかぎり多くのネットワーク帯域幅を使用することです。帯域幅の使用量が少なく、待機時間が長い場合は、TCPの設定のチューニングを検討してください。バックログまたはエラー率が高い場合も、ネットワーク構成の問題を示している可能性があります。ネットワークのチューニングを参照してください。