Saturn性能测试报告

1. 测试目的

• 评估zk集群可以负荷的域数量
• zk参数调优

2. 测试环境

ZooKeeper Ensemble (5)

Version: 3.4.6

Saturn Console (2):

Version: 2.1.3

Saturn Executor :

Version: 2.1.3

• 嵌入式实现；
• 不打印日志；

3. 测试场景

3.1 测试模型

3.1.1 变量定义

3.1.2 模型

• executorNumPerDomain = 3
• executorNum = executorNumPerDomain X domainNum = 3 X domainNum
• jobNumPerDomain = 35
• shardingItemPerJob = 3
• 作业调度频率：每分钟执行1次（时间随机）
• 作业类型：Shell
• 作业运行时长：2秒

3.2 场景

3.2.1 场景总览

• 场景1：（Benchmark）按照上述模型运行，获取benchmark。benchmark包括3个：没有任何作业下的性能（benchmark-0），200个域下的性能(benchmark-1)，400个域下的性能(benchmark-2)
• 场景2：（最大负载）通过增大域数量，其他参数保持不变，尝试获取集群的最大负荷；
• 场景3：（参数调优）在场景2的基础上，做zk配置调优；

3.2.2 具体测试用例

场景1 - Benchmark

场景2 - 最大负载

场景3 - 参数调优

4.测试方法

使用zk-smoketest的zk-latencies.py进行benchmark获取。

zk-latencies是一个比较通用的zk benchmark工具，由zookeeper的作者之一Patrick Hunt开发。

zk-latencies.py会用1个zk client执行下列的操作：

• Create: 创建持久节点
• Set: 更新节点数据
• Get: 获取节点数据
• Delete: 删除持久节点
• Create Ephemeral: 创建临时节点
• Watch: 使用exsits()对节点设置watch
• Delete Ephemeral: 删除临时节点

测试中所使用的zk-latencies 参数：

PYTHONPATH=lib.linux-x86_64-2.6 LD_LIBRARY_PATH=lib.linux-x86_64-2.6 ./zk-latencies.py 
--servers "<zk_cluster_ip>" 
--znode_count=100000 --znode_size=100 --synchronous

上述指令解释：调用同步接口分别调用5台zk server，获取benchmark。操作过程中所创建的节点大小固定为100bytes，操作的数量为100,000次。

5. 测试结果

为了便于比较，下面结果仅展现zk leader的结果。

5.1 场景1 - benchmark

5.1.1 zk 参数

JVM

-Djute.maxbuffer=104857600 
-Xms6g -Xmx6g -Xmn1500m -XX:+UseConcMarkSweepGC -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=75 
-XX:+ExplicitGCInvokesConcurrent -Xloggc:/dev/shm/gc_zk.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:ErrorFile=<your_log_dir>  
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=<your_log_dir> 
-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.authenticate=false 
-Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.port=8989 Djava.rmi.server.hostname=<zkip> 
org.apache.zookeeper.server.quorum.QuorumPeerMain

其中，JDK版本为1.7.0_79

zoo.cfg

# The number of milliseconds of each tick
tickTime=2000
# The number of ticks that the initial
# synchronization phase can take
initLimit=10
# The number of ticks that can pass between
# sending a request and getting an acknowledgement
syncLimit=5
# the directory where the snapshot is stored.
# do not use /tmp for storage, /tmp here is just
# example sakes.
dataDir=<your_dir>
dataLogDir=<your_dir>
# the port at which the clients will connect
clientPort=2181
# the maximum number of client connections.
# increase this if you need to handle more clients
maxClientCnxns=1000
minSessionTimeout=4000
maxSessionTimeout=60000
#
# Be sure to read the maintenance section of the
# administrator guide before turning on autopurge.
#
# http://zookeeper.apache.org/doc/current/zookeeperAdmin.html#sc_maintenance
#
# The number of snapshots to retain in dataDir
autopurge.snapRetainCount=10
# Purge task interval in hours
# Set to "0" to disable auto purge feature
autopurge.purgeInterval=2

5.1.2 结果

zk数据

TPS

• 上述每个操作都是执行100,000次获取的平均值；

TPS对比图

5.1.3 分析

当域的数量为200时，写性能没有下降，而读性能下降明显（~24%）；

当域的数量为400时，读写下降明显（>60%）。

5.2 场景2 - 最大负荷

5.2.1 zk 参数

与5.1.1一致

5.2.2 结果

zk数据

TPS

TPS对比图

Outstanding Size分布图

5.2.3 分析

• 700个域后，已经无法添加多100个域的作业。因此，700个域是当前测试配置下的最大负荷；
• 当zk的outstanding长期处于300以上，zk集群开始出现不稳定（见上图）

5.3 场景3 - 参数优化

5.3.1 Snapcount 调整

ZK会定时备份snapshot，而snapcount这个配置项影响了zk的落盘频率。下面这组测试是观察snapcount的大小（snapshot落盘频率）跟性能的关系。

5.3.1.1 zk 参数

在5.1.1描述的配置基础上，添加了-Dzookeeper.snapcount=xxx 参数，具体数值见下

5.3.1.2 结果

zk数据

TPS

TPS对比图

5.3.1.3 分析

• 随着snapcount的增大，读写性能有所提高；
• snapcount=10m从效果来看最佳，但是CreateEphemeral的性能跟snapcount=3m差不多；因此，后续测试还是沿用snapcount=3m进行

5.3.2 JDK调整

下面这组测试，是观察JDK不同版本对ZK性能的影响。

5.3.2.1 zk 参数

在5.1.1描述的配置基础上添加了-Dzookeeper.snapcount=3000000，以及修改了JDK版本为“1.8.0_102”

5.3.2.2 结果

zk数据

TPS

TPS对比图

5.3.2.3 分析

• 使用了JDK8后性能有明显提升。(JDK8其中一个优化点是对Atomic相关类的优化，而ZK的实现使用了大量的Atomic，详情可以参考这里)

6. 总结

• 本次测试获取了2个benchmark：测试模型下的200个域以及400域的性能；
• 按照测试模型，最多能承受700个域；
• 使用JDK8以及调整snapcount到合适的值有助于改善性能；