Zookeeper压力测试.docx

Zookeeper压力测试?压力测试情况通过对zk并发测试，在800个连接并发创建80万数据时，每个zk虚机节点的磁盘IO达到瓶颈。由于磁盘性能限制，tps基本在9000左右。根据官方的一份测试情况来看，tps在3万以上问题不大（测试环境差异）。通过iostat查看，%util在70%以上，说明cpu大部分时间都消耗在磁盘io请求的处理上。单节点每秒在几十MB左右。通过lsof查看，磁盘性能主要消耗在zk自身的操作日志、数据快照、运行日志三部分文件上。目前建议如果资源充足情况下，生产环境压力上来时，可以将操作日志与数据快照存在不同磁盘。另一方面，随着负载的增大，日志文件产生过多会占用大量磁盘，而时间较长的历史数据又没有参考价值，建议做定期删除操作。可以通过crontab添加定时任务，或者通过zk自身配置：#执行频率单位小时autopurge.purgeInterval=1#保存数量autopurge.snapRetainCount=100?iostat -x -k 2avg-cpu:? %user?? %nice %system %iowait? %steal?? %idle????????? 10.55??? 0.00?? 18.73?? 21.64??? 1.58?? 47.49?Device:???????? rrqm/s?? wrqm/s???? r/s???? w/s??? rkB/s??? wkB/s avgrq-sz avgqu-sz?? await? svctm? %utilscd0????????????? 0.00???? 0.00??? 0.00??? 0.00???? 0.00???? 0.00???? 0.00???? 0.00??? 0.00?? 0.00?? 0.00vda?????????????? 0.00 23052.74??? 1.00 3979.60???? 3.98 94477.61??? 47.47??? 19.89??? 4.71?? 0.19? 75.87?avg-cpu:? %user?? %nice %system %iowait? %steal?? %idle?????????? 8.99??? 0.00?? 16.93?? 15.87??? 1.32?? 56.88?Device:???????? rrqm/s?? wrqm/s???? r/s???? w/s??? rkB/s??? wkB/s avgrq-sz avgqu-sz?? await? svctm? %utilscd0????????????? 0.00???? 0.00??? 0.00??? 0.00???? 0.00???? 0.00???? 0.00???? 0.00??? 0.00?? 0.00?? 0.00vda?????????????? 0.00? 6958.00??? 0.50 4223.50???? 2.00 44066.00??? 20.87???? 2.04??? 0.76?? 0.18 ?75.75注：%util?Percentage of CPU time during which I/O requests were issued to the device.?附上测试情况?测试环境：Zk集群：三个zk节点组成集群双cpu 2.4G内存：4G磁盘45G?通过不同连接数并发进行如下操作：每个连接创建1000个节点，每个节点大小1024B，进行相应的create、get、set、delete、watch操作。连接数从100到1000。当连接数达到1000时，由于磁盘瓶颈导致zk集群出现问题。?测试结果：Create set和get的数据波动原因是zk要对所有的操作以及数据进行持久化，磁盘io压力过大。在此压力下数据创建没有失败情况。??补充与1节点zk对比测试结果：?测试中发现的相关问题记录一.maxClientCnxns配置之前讨论的maxClientCnxns配置，是针对一个客户端ip下连接数的限制，而不是针对有多少连接连到了集群或者这个zk节点。目前生产环境下5个zk节点的集群承担着总共约550个客户端连接，创建了约7万个数据节点。负载相对不高，连接数变化也不会大，目前应该不需要考虑限制连接的问题。二.事务日志和快照策略?三.相同压力下创建成功但删除失败问题跟踪在建立1000个连接，每个连接创建1000个znode，每个znode 1024B的情况下，创建全部成功。但是在delete操作时，测试过程一致，但是会出现部分回话超时，连接被断开的问题，导致10w个节点中5w个无法删除的问题。所以，我从集群状况，磁盘IO，cpu，jvm GC等几个方面逐步分析。集群延迟通过四字命令mntr