go-ycsb测试,CPU压力大的情况下集群性能情况

测试目的:在某个节点CPU负载较高的情况下集群稳定性
测试拓扑:三台机器,每台1个tikv-server节点,pd-server单独部署
测试过程:
1、go-ycsb工具写入初始数据
2、服务器CPU无特殊负载情况下读已经写入的数据(go-ycsb工具)
3、某个节点使用stress工具占用大部分CPU资源,读已经写入的数据(go-ycsb工具)

前后QPS对比,发现集群CPU空闲情况下集群比CPU繁忙情况下的QPS高很多,按自己理解:某个节点CPU高,这个节点上的region读请求慢是正常的,不应该影响其他节点的读,实际测试结果是某个节点CPU资源不足,直接影响了当前整个集群的请求,是我理解错了吗,读操作和整个peer节点都有关系?还是集群配置有问题?


CPU无压力QPS:


stress加压QPS:



1赞

辛苦提供一下 测试的配置信息

1赞

go-ycsb配置吗?

1赞

对的,压测配置信息


:handshake:

1、TiDB集群某节点CPU高了,慢了是有可能影响到整个集群的吞吐的。
2、某个节点上TiKV CPU高了,那么你的读如果有需要读到这台压力大上面的Leader Region,一样需要等待这个返回的,所以整体的性能会降低。
3、可以通过查看监控,排查下现在的瓶颈出现在哪里。

CPU高的那个节点慢是能理解的,我主要的疑问是,这台慢了,其他CPU正常的节点从QPS上看感觉也变慢了,按region的leader分别来说,CPU繁忙的点占1/3,总体QPS是不是最多降1/3?

并不完全是的:
1、要看你在这台机器上Region leader是否只占用了1/3
2、而且即使是占用了1/3,还得根据你这些QPS是否有请求到这台机器的Leader,是否有热点打到这些Region
3、而且这是一个整体的系统,某些节点慢可能触发流控的。
所以不能简单这么计算,应该分析下这个节点为什么,进行优化。

嗯嗯,看监控leader差不多是1/3,我测试是故意让一个点CPU繁忙,被流控了有监控可以看吗?