Multi-Raft 性能问题探究

现象：

基于 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 链接

Unable to render Jira issues macro, execution error.

分析：

Timer：

分析内部记录的 timer，可以看到耗时基本是等比例增加的，没发现某处具有瓶颈点，很自然的便开始怀疑 GC 问题。

multi-raft-factor=1

multi-raft-factor=3

GC log

通过 jprofile 和 gc log 均观察到 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 功能在高并发情况下不一定能够带来稳定的提升，主要原因是 Raft 的内存控制工作还不够完善，默认参数可能会导致内存紧张 GC 频繁。

通过此次测试工作，可以明确分布式的内存控制势在必行。