0

Cassandra で一連のベンチマークを実行しています。とりわけ、次の構成を試しました: 1 つのクライアント ノード、3 つのサーバー ノード (同じリング)。すべての実験は、サーバーをクリーンアップした後に実行されます。

pkill -9 java; sleep 2; rm -r /var/lib/cassandra/*; ./apache-cassandra-1.2.2/bin/cassandra -f

次にcassandra-stress、クライアント ノードから実行します ( 3 レプリカ、整合性 ANY/ALL):

[stop/clean/start servers]
./tools/bin/cassandra-stress -o INSERT -d server1,server2,server3 -l 3 -e ANY
[224 seconds]
[stop/clean/start servers]
./tools/bin/cassandra-stress -o INSERT -d server1,server2,server3 -l 3 -e ALL
[368 seconds]

一貫性レベルを下げると、パフォーマンスが向上すると推測できます。ただし、これが発生する理由はありません。ボトルネックはサーバーの CPU であり、最終的にはすべてローカル書き込みを行う必要があります。実際、サーバー ログを注意深く読むと、ほのめかされたハンドオフが行われたことがわかります。実験を繰り返していると、クライアントで UnavailableException が発生し、サーバーで「MUTATION メッセージがドロップされました」というメッセージが表示されることがあります。

この問題は文書化されていますか? CL != ALL は書き込み時に有害と見なされるべきですか?

4

1 に答える 1

0

あなたの主張が何なのかよくわかりません。物事は設計どおりに機能しているように見えます。

はい、CL.ONEで書き込んでいる場合は、CL.ALLよりも速く書き込みが完了します。これは、すべてではなく、1つのノードからACKを取得するだけでよいためです。

ただし、データの修復にかかる時間を測定しているわけではありません。ヒントされたハンドオフのキューイングと処理に時間がかかりますが、ノードはこれを1時間しか保持しません。

最終的には、を実行しnodetool repairて整合性を修正し、トゥームストーンを削除する必要があります。

于 2013-03-04T22:59:23.843 に答える