2

16GB RAM を搭載した 8 コア マシンで実験的なシステム セットアップのパフォーマンスを評価しています。私は 2 つのメイン メモリ Java RDBMS (hsqldb) を実行しており、これらのそれぞれに対して (jTPCC/BenchmarkSQL から派生した) TPCC クライアントを実行しています。

私は物事を起動するためのスクリプトを持っているので、例えば hsqldb インスタンスは以下で開始されます:

./hsqld.bash 0 &
./hsqld.bash 1 &

ほぼ同時にクライアントを起動した場合:

./hsql-tpcc.bash 0 &
./hsql-tpcc.bash 1 &

次に、これらの各クライアントの初期レートが約 500 ～ 1000 tpmC (基本的には 1 分あたりのトランザクション数) で急上昇し、その後すぐに (1 秒以内に) 約 200 ～ 250 tpmC のレートに落ち着きます。OTOH、2 番目のクライアントを開始する前に 1 ～ 2 秒待つと、次のようになります。

./hsql-tpcc.bash 0 &
sleep 1
./hsql-tpcc.bash 1 &

次に、各クライアントは 2500+ tpmC で実行されます。1 秒以上待っても、それ以上の違いはありません。

クライアント 0 はサーバー 0 と通信し、クライアント 1 はサーバー 1 と通信するだけなので、これは奇妙です。なぜこのような劇的なパフォーマンスの干渉があるのか​​は不明です。

これはクライアントの CPU スケジューラ アフィニティによるのではないかと考えましたが、低速で実行するとシングル コアの約 1 ～ 3% しか使用しません (高速で実行すると 20 ～ 25%)。別の疑いは、クライアントの NUMA バインディング (同じメモリ ノードでのメモリ競合) にありましたが、マシンにはメモリ ノードが 1 つしかなく (/sys/devices/system/node/node0 しかありません)、さらに各クライアントはわずか 0.8% しか使用していません。メモリの。

また、hsqldb インスタンスの CPU バインディングが原因であるとは思われません。クライアントを再起動するだけで (そして 1 秒間待機する/待機しない)、高速と低速の両方の動作が見られ、両方で同じ hsqldb インスタンスが実行されたままになるためです (つまり、 hsqldb を再起動する必要はありません)。hsqldb は、低速の場合は 4 ～ 8% の CPU、高速の場合は 80% の CPU、および 4.3% のメモリを消費します。

なぜこれが起こっているのか、他のアイデアはありますか？ディスク IO は関係なく、システムのメモリを使い果たすことはほとんどありません。前もって感謝します。その他の関連情報は次のとおりです。

$ uname -a
Linux hammer.csail.mit.edu 2.6.27.35-170.2.94.fc10.x86_64 #1 SMP Thu Oct 1 14:41:38 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
4

1 に答える 1

1

テストの前に、「2つのメインメモリJava RDBMS（hsqldb）」がどのくらい実行されていますか？テストの直前に開始する場合は、最初に少しウォームアップしてみてください。if (first_time) { do_initialization(); }ホットスポットにそれをさせて、ガベージコレクターが落ち着くことができるようにデータベース内のすべてのコードを調べてください。

また、（それらが何であれ）同時に2つのことを開始するということは、最小限、両方が同時にすべてのinit作業（メモリの割り当て、スワップでのページの割り当て、ライブラリの検索とロードなど）を実行しようとしていることを意味します。 ）。したがって、どちらのプログラムも、人生の最初の数ミリ秒をI/O競合に費やします。

于 2010-01-11T02:15:42.620 に答える