现象:
基于 master 0.13,5 节点 2 副本集群在关闭 RaftLog 持久化后,设置 multi-raft-factor 的参数从 1 到 3 后性能下降接近一倍。
配置:
机器:
内存:32G
CPU:16 核
客户端:
CLIENT_NUMBER=60 GROUP_NUMBER=20 DEVICE_NUMBER=60 SENSOR_NUMBER=8000 BATCH_SIZE_PER_WRITE=1 LOOP=2500 POINT_STEP=200 OP_INTERVAL=0 BENCHMARK_CLUSTER=true IS_OUT_OF_ORDER=false OUT_OF_ORDER_RATIO=0.3
服务端:
default_replica_num=2 multi_raft_factor=1/3 is_enable_raft_log_persistence=false
jira 链接
分析:
Timer:
分析内部记录的 timer,可以看到耗时基本是等比例增加的,没发现某处具有瓶颈点,很自然的便开始怀疑 GC 问题。
multi-raft-factor=1
multi-raft-factor=3
JProfile
观察到 multi-raft-factor 增大后 GC 明显变得严重,这主要是当前对于 multi-raft 没有进行有效的内存控制导致的。即每个 raftlogmanager 都具有一个 512 MB 的日志缓存,raft 组数增加后进一步增大了内存的紧张程度,从而导致 FGC 更加频繁,最终影响性能。具体可以参考该文档查看分布式 raft 内存控制的问题和解决方案。
multi-raft-factor=1
multi-raft-factor=3
回顾:
参照之前开发该功能时的测试记录,在 768 G 内存的机器上测试 multi-raft-factor 参数的作用,当内存不紧张 GC 不频繁时,性能提升十分明显。具体可以参考此文档。
总结:
当前的 multi-raft 功能在高并发情况下不一定能够带来稳定的提升,主要原因是内存控制工作还不够完善,默认参数可能会导致内存紧张 GC 频繁。
通过此次测试工作,可以明确分布式的内存控制势在必行。