You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Current »

现象：

基于 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 不频繁时，性能提升十分明显。具体可以参考此文档。



补充实验 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 组的资源消耗。




  • No labels