20T的集群现在停了，leader基本是均衡的，weight值没改
扩容之后是哪一段？
1 个赞
差不多平均0.08ms，网络应该不是问题，新tikv和原有的pd部署一套集群测试，100并发，tps能到5200
1 个赞
我发的两个图都是扩容后的
数据量太小，这个级别适合单机数据库，规模越大效果越差
1 个赞
同感是单表数据量小，服务器数量太多反而因为通信拉低性能了
2 个赞
楼主，问题解决了吗啊
差不多算是解决了吧，就是将旧机器每个服务器缩容为1个实例，新机器每个服务器部署2个实例，先达到每个实例资源基本均衡，后来测试过程中又发现了两个问题：
- 集群有20T数据和空集群压测tps相差较大，有20T数据的tps低，空集群tps高，相差30%
- 就像楼上说的，数据太少也不行，8个100万的表，100并发，tps是4800，但是8个1000万的表，tps到5800了，这种场景是新旧服务器共12台tikv部署一个大集群，空集群，只有压测数据
整体来说还是集群服务器数量少，反而性能高，服务器多，性能并不是同等增长的，也考虑了拆分为两个集群，那样两个集群的加起来的性能远大于一个大集群的性能，但是线上等着使用，来不及了
sysbench测的哪个模块方便说下吗？
oltp.lua
是OLTP整个模块吗？还是其中某一个？比如oltp_select_point、oltp_read_write
/usr/share/sysbench/tests/include/oltp_legacy/oltp.lua
1 个赞
这不合理啊，不应该集群规模越大，性能越高么
1 个赞
根据测试情况，我的理解是这样的：
- 集群越大，性能越高，是建立在具有一定数据量，并且是高并发的基础上的
- 对于低并发的情况，比如10个并发，在一个大集群里跑，反而性能会降低，因为分布式增加了通信成本
- 比如有两个集群，一个是3台服务器的小集群，一个是30台服务器的大集群，跑10个并发压测，小集群反而会发挥出优势，因为通信成本低，所以tps会比大集群高；但是如果跑1000个并发，大集群就发挥出优势了，因为处理能力强，而小集群的资源就成了瓶颈
总之，在能够承受业务数据量和并发量的情况下，tikv服务器越少，性能越好，而不是集群越大越好。
不知道这样理解是否正确，还请指正
仔细一想，还真有可能是这种情况。
1 个赞
此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。