Question

我已经写过Cassandra 3的性能问题。

我正在尝试使用此处的官方Docker图像来尝试Cassandra 3.3：https://github.com/docker-library/cassandra

我按如下方式开始：

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

然后对它运行cassandra-stress：

cassandra-stress write

这为四个执行流量的线程提供了以下结果：

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

使用官方图片为Cassandra 2.2做同样的事情：

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

通过四个主题给我以下结果：

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的写入次数/ s几乎降低了15％。这可能是什么原因？我一直在尝试更改各种参数，包括在Oracle上运行Cassandra（与OpenJDK相比），没有显着差异。我也尝试过不同版本的Cassandra 3，没有发现真正的差异。我知道这是一个单一节点，并且此基本测试的结果无法转移到生产设置。不过，我很想知道是否有人有解释或可以重现这种行为。

欢迎任何输入！

更新2016-04-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数量相当有限的环境中进行实验。我还没有对更强大的硬件进行任何实验，看看这个标志的影响是什么。

Answer 2

你进行了多少次测试？

请记住，单次01:40分钟的运行远不是性能测试的全面性

Cassandra v.3，写性能问题

2 个答案: