カサンドラのV 3、私はカサンドラ3.</p> <p>と書き込みパフォーマンスの問題を持っているパフォーマンスの問題

Question

を書く私はここから公式ドッカーの画像を使用してカサンドラ3.3を実行しようとしている：。https://github.com/docker-library/cassandra

次のように私はそれを起動します。

docker run --net=host --rm cassandra:3.3 

そして、それに対してカサンドラ・ストレスを実行します。

cassandra-stress write 

これは私のトラフィックを実行する4つのスレッドのために以下のような結果が得られます。公式の画像使用カサンドラ2.2の正確な同じことをやっ

op rate     : 1913 [WRITE:1913] 
partition rate   : 1913 [WRITE:1913] 
row rate     : 1913 [WRITE:1913] 
latency mean    : 2.1 [WRITE:2.1] 
latency median   : 1.6 [WRITE:1.6] 
latency 95th percentile : 4.1 [WRITE:4.1] 
latency 99th percentile : 8.4 [WRITE:8.4] 
latency 99.9th percentile : 20.5 [WRITE:20.5] 
latency max    : 155.4 [WRITE:155.4] 
Total partitions   : 154607 [WRITE:154607] 
Total errors    : 0 [WRITE:0] 
total gc count   : 13 
total gc mb    : 1951 
total gc time (s)   : 1 
avg gc time(ms)   : 59 
stdev gc time(ms)   : 28 
Total operation time  : 00:01:20 

：

：

docker run --net=host --rm cassandra:2.2 

は私に4つのスレッドで次のような結果になります

op rate     : 2248 [WRITE:2248] 
partition rate   : 2248 [WRITE:2248] 
row rate     : 2248 [WRITE:2248] 
latency mean    : 1.8 [WRITE:1.8] 
latency median   : 1.4 [WRITE:1.4] 
latency 95th percentile : 3.5 [WRITE:3.5] 
latency 99th percentile : 7.2 [WRITE:7.2] 
latency 99.9th percentile : 16.4 [WRITE:16.4] 
latency max    : 129.5 [WRITE:129.5] 
Total partitions   : 195461 [WRITE:195461] 
Total errors    : 0 [WRITE:0] 
total gc count   : 11 
total gc mb    : 1612 
total gc time (s)   : 1 
avg gc time(ms)   : 62 
stdev gc time(ms)   : 21 
Total operation time  : 00:01:26 

書き込み/秒の数は2.2に比べ3.3で約15％低いです。その理由は何でしょうか？私は、上記のOpenJDKと比較して、Oracle上でCassandraを実行することを含め、重要な違いなしに、さまざまなパラメータを変更しようとしてきました。私はカサンドラ3の異なるバージョンを試しましたが、実際の違いは見つかりませんでした。私はこれが単一ノードであり、この基本テストの結果を本番環境に移すことはできないことを知っています。それでも、誰かが説明を持っているのか、その行動を再現できるのかどうか知りたいのは興味深いです。

すべての入力を歓迎します！

アップデート2016年4月13日、JVMパラメータの違い：

diff jvm-param22-sorted jvm-param33-sorted 

> -XX:+AlwaysPreTouch 
# Before removing this from the 3.3 config: 
# USER  PID %CPU %MEM VSZ RSS TTY  STAT START TIME COMMAND 
# cassand+  1 19.0 30.3 2876304 1229136 ?  Ssl 04:18 0:17 java 
# 
# After removing it: 
# USER  PID %CPU %MEM VSZ RSS TTY  STAT START TIME COMMAND 
# cassand+ 177 17.0 9.4 2885596 383972 ?  Sl+ 04:59 0:17 java - 
# 
# The above could actually explain some of the issues that I've observed in 
# low memory environments with multiple containers running since I guess it 
# means Cassandra will grab the whole heap at startup from the OS 
# regardless of the actual need.  

# This was present twice in the 22 config. Should not matter. 
< -XX:CMSWaitDuration=10000 

# Removing this from the 3.3 config did not have any significant impact 
> -XX:+ResizeTLAB 

# Removing from the 3.3 config did not have any significant impact 
> -XX:-UseBiasedLocking 

# Adding this one to the 3.3 config did not have a significant impact 
< -XX:+UseCondCardMark 

Answer 1

のための包括的であることから、私はただ今後の参考のために自分にお答えしますしていることに注意してください。私の場合の犯人は、JVMのパラメータ-XX：+ AlwaysPreTouchです。これは、Cassandraの3.0リリースでデフォルトとして追加されました。これを削除すると、パフォーマンスは2.2リリースと同じレベルに戻ります。

私は主にRAMの量がかなり限られた環境で実験しました。私はまだ、この旗の効果が何であるかを見るために、より強力なHWについて実験を行っていません。

Answer 2

テストを実行でした何回？

は、1：40分の回の実行がはるかに性能試験