...
参照之前开发该功能时的测试记录,在 768 G 内存的机器上测试 multi-raft-factor 参数的作用,当内存不紧张 GC 不频繁时,性能提升十分明显。具体可以参考此文档。
补充实验 1
...
思路:
...
:降低负载,增大空闲内存。检验 multi-raft-factor 不同值时的性能对比。
配置变化:
- sensorNum 大小从 8000 降低为 800,读写内存分配为 4:1:1:4。
...
- 当 GC 不频繁时,multi-raft-factor 增大后性能略有下降。可以证明开启 增大后性能下降 4%。可以证明开启 multi-raft-factor 不会导致明显的性能下降,在误差范围内性能基本一致。然而,与之前的测试结论不符,通过 timer 发现基本没有抢锁的耗时,通过测试该机器发现节点间的带宽为 300MB/s ,之前测出性能大幅提升的节点间的带宽为 12.5GB/s,因而猜测当网络很慢时,raftLogManager 的锁不会成为瓶颈。
multi-raft-factor = 1
multi-raft-factor = 3
补充实验
...
思路:
...
2:回到之前高速网络的机器上,检验 multi-raft-factor 不同值时的性能对比。
配置:
两节点两副本,1 benchmark 60 并发 20 存储组。
结论:
- multi-raft-factor 增大后性能性能依然小幅度下降。从 1 变为 3 后性能下降 5%。
- 通过 timer 判断可能是客户端压力不够。
multi-raft-factor = 1
multi-raft-factor = 3
补充实验
...
3:提高客户端压力,检验 multi-raft-factor 不同值时的性能对比。
配置:
两节点两副本,multi-raft-factor 分别为 1 和 20。1 benchmark,每个 benchmark 400 并发 40 存储组,共 6400 个 device,每个 device 一个 sensor,batchsize = 100。
结论:
- multi-raft-factor 增大之后性能小幅上升。增大之后性能上升 20%。
multi-raft-factor = 1
multi-raft-factor = 20
补充实验 4:进一步提高客户端压力,检验 multi-raft-factor 不同值时的性能对比。
配置:
两节点两副本,multi-raft-factor 分别为 1 和 20。2 benchmark,每个 benchmark 400 并发 40 存储组,共 6400 个 device,每个 device 一个 sensor,batchsize = 100。
结论:
- 相比补充实验 3 ,对于 multi-raft-factor 为 20 的集群,客户端负载增加一倍后吞吐从 20 万下降到了 11 万,性能下降了约 1 倍;对于 multi-raft-factor 为 1 的集群,客户端负载增加一倍后吞吐从 16 万下降到了不到 2 万,性能下降了约 8 倍。
- 对于相同的客户端负载,multi-raft-factor 为 20 的集群是 multi-raft-factor 为 1 的集群的 6 倍。
- multi-raft 并不一定能够带来性能提升,只是如果不开 multi-raft 的话,在高并发时性能会急速下降。
multi-raft-factor = 1
multi-raft-factor = 20
总结:
经过对 multi-raft 功能的测试,可以明确以下结论:当前的
- multi-raft 的内存控制还不够完善,默认参数可能会导致内存紧张 GC 频繁,反而导致性能下降。
- 在正常负载时,mutli-raft 开启与否对性能影响在可接受线以内(5%),更多的 raft 组不可避免的会占据更多的系统资源,这一块也可以进一步去优化来减少对性能的影响。
- 在高并发负载时,不开启 multi-raft 可能会导致性能急速下降,此时开启 multi-raft 能够减少性能下降的幅度。
通过此次测试工作,可以明确 multi-raft 功能在新一版架构中依然会存在,我们不仅需要和单机一起设计完善的写入内存控制策略,避免 GC 对性能的影响,还要进一步尝试去优化单 raft 组的资源消耗。 功能在高并发情况下不一定能够带来稳定的提升,主要原因是 Raft 的内存控制工作还不够完善,默认参数可能会导致内存紧张 GC 频繁。通过此次测试工作,可以明确分布式的内存控制势在必行。