1

YCSB ベンチマーク ツールを使用して、Cassandra クラスターのベンチマークを行っています。クラスター内の仮想マシンの数を変えています。1 台の物理ホストを使用しており、ベンチマーク用に 1、2、3、4 台の仮想マシンを使用しています (添付の図を参照)。

生成されるワークロードは常に同じ ワークロード C 10,000,00 回の操作、10,000 のレコード 各 VM には 2 GB の RAM、20 GB のドライブがあります

Cassandra - 1 シード ノード、endpoint_snitch - gossipproperty キースペース YCSB - レプリケーション ファクター 3、

問題は、クラスター内の仮想マシンの数を増やすと、スループットが低下することです。その理由は何ですか？

定義上、コンピューティング リソース (つまり仮想マシン) を増やすことによって、クラスターはより良いパフォーマンスを提供するはずですが、添付の図に示すように、逆のことが起こっています。考えられる理由を教えてください。このトピックについて論文を書いていますが、その理由がわかりません。助けてください。よろしくお願いします。

Cassandra クラスター内のさまざまな数の VM で観測されたスループット: cassandra クラスター内のさまざまな数の VM で観測されたスループット

4

2 に答える 2

4

ディスク IO のボトルネックにぶつかる可能性が非常に高いです。特に SSD 以外のドライブの場合、これは完全に予想されることです。仮想マシンごとに専用のディスク/CPU がない限り、リソースの競合によってこのような競合が発生します。また、推奨される最小の JVM ヒープ サイズは 8 GB であるため、VM あたり 2 GB では、Cassandra であらゆる種類のパフォーマンス ベンチマークを実行するには十分ではありません。

于 2016-01-24T00:51:53.417 に答える
3

Cassandra は水平スケーリング (ほぼ線形) に優れていますが、1 つの物理ホストに VM を追加するだけでスループットが向上するわけではありません。物理ホスト上の単一の VM では、リソース (ディスク、CPU、メモリ、ネットワーク) の競合が少なくなります。 ) は 4 よりも多いため、1 つの VM のパフォーマンスが 4 よりも優れている可能性があります。

定義上、リソースを増やしていれば、パフォーマンスが向上するはずですが、そうではなく、単に既存のリソースに競合を追加しているだけです。cassandra をスケーリングする場合は、物理リソースを追加してテストする必要があります。同じマシン上で VM を増やすのではなく、物理マシンを増やす必要があります。

最後に、Chris Lohfink が言及しているように、VM は小さすぎて意味のあるテストを行うことができません。8 GB の JVM ヒープが推奨され、読み取りをサポートするために 8 GB の vm ページ キャッシュがさらに必要です。

ジェット エンジン (数百または数千の物理ノード用に設計された分散データベース) をガソリン スタンド レベルの機器でテストしようとしています。ベンチマーク ハードウェアは実際の運用環境では実行できないため、ベンチマークの結果は意味がありません。 .

于 2016-01-24T20:10:03.300 に答える