無料PHPプログラム

ndbd プロセスには多くの簡単な構成があり、MySQL Cluster のアクセスに使用します。それらのパフォーマンスおよび様々なインターコネクトがそのパフォーマンスに及ぼす影響をチェックする簡単なベンチマークを作成しました。

4 つのアクセス方法があります。

これらのアクセス方法の基本的なパフォーマンスをチェックするために、一連のベンチマークを開発しました。そのようなベンチマークの一つは、testReadPerf、でｎ簡単なバッチのプライマリおよび一意のキーアクセスをテストします。このベンチマークはまた 1 つのレコードを返すスキャンを発行することで範囲スキャンの設定コストを測定します。範囲スキャンを使用してレコードのバッチを取り出すこのベンチマークの派生版もあります。

この様に、基本となるアクセス方法で、使用している通信メディアの影響を測定するばかりでなく、1 つのキーアクセスおよび 1 つのレコードスキャン アクセスの両方のコストを決定できます。

弊社のテストでは、これらのベンチマークを TCP/IP ソケットを使用した通常のトランスポーターおよび SCI ソケットを使用した類似の設定の両方に使用しています。以下テーブルのレポートした図はアクセス毎に 20 レコードの小さなアクセスに使用します。シリアルおよびバッチのアクセスは 2KB のレコードを使用した場合 3 と 4 の因数が減少します。SCI ソケットは 2KB レコードでテストしていません。テストは AMD 社の MP1900+ プロセッサを搭載した 2 つのデュアル CPU マシン上で動作する 1 つのクラスタに 2 つのデータ ノードで実行しました。

SCI ソケット vis-a-vis と SCI トランスポーターのパフォーマンス、およびこれら両方を TCP/IP トランスポーターと比較したパフォーマンスをチェックしました。これらすべてのテストにはプライマリ キーアクセスをシリアルおよび複数のスレッド、あるいは複数のスレッドおよびバッチのいずれかに使用しました。

このテストでは SCI ソケットが TCP/IP よりもおよそ 100% 早いことが分かりました。SCI トランスポーターは SCI ソケットに比べると殆どのケースで速くなっています。テスト プログラムの多くのスレッドで注目すべきことが発生した。それは SCI トランスポーターは mysqld プロセスに使用した場合あまりよい結果を示しませんでした。

全体的な結論としては、通信のパフォーマンスが懸案でないときの珍しいインスタンスを除いて、ほとんどのベンチマークで、SCl ソケットは TCP/IP に対しておよそ 100% パフォーマンスを改善することです。これはスキャンのフィルタが殆どのプロセス時間を使った場合あるいはプライマリ きーの非常に大きなバッチ アクセスが達成されたときに起こります。その様な場合、ndbd プロセスの CPU の処理がオーバーヘッドのかなり大きな部分になります。

SCI ソケットの代わりに SCI トランスポートを使用するには、ndbd プロセス間の通信の端に興味によるものです。SCI トランスポーターを使用するのも単なる興味からで、SCl トランスポーターがこのプロセスが決して停止しないことを確認するため、CPU を ndbd プロセスに専用にできるかとの単なる興味からのものです。ndbd プロセスの優先権がプロセスが、Linux 2.6 でプロセスをロックできるように、時間を延長して実行されても優先権がなくならないように設定されているか確認する必要があります。そのような設定が可能な場合、ndbd プロセスは SCI ソケットを使用した場合に比べて 10?70% 恩恵があることになります。(更新および並列スキャンのオペレーションでは大きな数字になります。)

コンピュータのクラスタに Myrinet、ギガビット Ethernet、Infiniband および VIA インターフェースなど他にもいくつかの最適化ソケットの実装があります。これまでに MySQL Cluster を SCI ソケットだけでしかテストしていません。通常の TCP/IP を MySQL Cluster 使用した SCI ソケットの設定方法については、項14.12.1. 「SCI ソケットを使用するための MySQL Cluster の設定」 を参照してください。