Page History

...

参照之前开发该功能时的测试记录，在 768 G 内存的机器上测试 multi-raft-factor 参数的作用，当内存不紧张 GC 不频繁时，性能提升十分明显。具体可以参考此文档。

补充实验 1 ：

思路：

• 降低负载，增大空闲内存。检验 multi-raft-factor 不同值时的性能对比。

配置变化：

• sensorNum 大小从 8000 降低为 800，读写内存分配为 4:1:1:4。

结论：

• 当 GC 不频繁时，multi-raft-factor 增大后性能略有下降。可以证明开启 multi-raft-factor 不会导致明显的性能下降，在误差范围内性能基本一致。然而，与之前的测试结论不符，通过 timer 发现基本没有抢锁的耗时，通过测试该机器发现节点间的带宽为 300MB/s ，之前测出性能大幅提升的节点间的带宽为 12.5GB/s，因而猜测当网络很慢时，raftLogManager 的锁不会成为瓶颈。

multi-raft-factor = 1

Image Added

multi-raft-factor = 3

Image Added

补充实验 2：

思路：

回到之前高速网络的机器上，检验 multi-raft-factor 不同值时的性能对比。

配置：

两节点两副本，1 benchmark 60 并发 20 存储组。

结论：

•  multi-raft-factor 增大后性能性能依然小幅度下降。
• 通过 timer 判断可能是客户端压力不够。

multi-raft-factor = 1

Image Added

Image Added

multi-raft-factor = 3

Image Added

Image Added

补充实验 3：

提高客户端压力，检验 multi-raft-factor 不同值时的性能对比。

配置：

两节点两副本，multi-raft-factor 分别为 1 和 20。1 benchmark，每个 benchmark 400 并发 40 存储组，共 6400 个 device，每个 device 一个 sensor，batchsize = 100。

结论：

•  multi-raft-factor 增大之后性能小幅上升。

multi-raft-factor = 1

Image Added

Image Added

multi-raft-factor = 20

Image Added

Image Added

总结：

当前的 multi-raft 功能在高并发情况下不一定能够带来稳定的提升，主要原因是 Raft 的内存控制工作还不够完善，默认参数可能会导致内存紧张 GC 频繁。

...