在grafana的overview里面看看systeminfo那部分，cpu 内存和io有没有跑满的
1 个赞
虚机测有可能资源抢占的吧，有监控的话可以看看是否存在瓶颈
1 个赞
使用本地磁盘，不用云盘
1 个赞
有的，看了下，测试的时候基本都跑满了。
你压力瓶颈全在CPU上了，把PD和TiDB server拆开，同时把tidb server扩到两个，压测主机上搭个haproxy，指向两个tidb server，再试试
P.S：你压测客户端不会和tidb server在同一台机器上吧？
1 个赞
是在一个客户端 
，压测主机要专门弄个节点吗？这个没有考虑到。
虚拟机的话，看一下，是不是有 共用宿主机的
1 个赞
压测客户端最好单独一台机器，并且高cpu核，比如要压到400并发最好32C以上
如果在一起的话，你客户端发起请求不就和tidb server、pd一起争用cpu？
2 个赞
显然是cpu到瓶颈了
1 个赞
大佬，今天测试了下，将sysbench节点放在另一个虚拟机上，测试了下，100并发，性能没有原来的好，tidb和pd节点还是放在一起的，压测单独放一个虚拟机上的。测试的时候cpu都到瓶颈了。
这是刚测的
这是上次测的
没有想明白为什么还不如上次测的。
你压测机多少C？
现在的tidb部署架构是什么
另外来几张监控图
10的CPU还是瓶颈，这样，改下部署
在11 12 13上各部署一个tidb pd tikv ，10上搭个haproxy，指向三个节点，压测机走10的haproxy
1 个赞
好的，感谢大佬，我去试试。 
建议单机单实例
1 个赞
所有结果跑出来了，100线程还能看看，超过100简直了，所以就没跑100以上的了。各位大佬有兴趣了空闲的时候可以看看，下次再跑这种测试，一定搭个标准的环境。
point_select_10 (8.3 KB)
point_select_50 (8.3 KB)
point_select_100 (8.3 KB)
read_write_100 (8.6 KB)
read_write__10 (8.4 KB)
read_write_50 (8.6 KB)
update_index_10 (8.1 KB)
update_index_50 (8.2 KB)
update_index_100 (8.3 KB)
update_non_index_10 (8.1 KB)
update_non_index_50 (8.2 KB)
update_non_index_100 (8.3 KB)
单节点tidb的要把所有节点都测完，然后合计吧
1 个赞