之前用的机械，后面复现问题用的wsl,wsl在ssd上，samsung ssd980 1T，1pd 1tidb 3kv 和监控
建议修改一下sbtest的表结构，改成打散结构，参考这里
https://docs.pingcap.com/zh/tidb/stable/troubleshoot-hot-spot-issues#使用-auto_random-处理自增主键热点表
1 个赞
是的，但是这好像并不会导致tps很低，因为我发现，在空表的时候前面tps可以打到1000多，然后开始下降到最后平均为600，这个时候 磁盘ioutil一直满的，磁盘写入带宽能到600mb，然后停10分钟后，再测tps稳定300，此时带宽是300mb，ioutil还是满的，即使我不压，kv的cpu还是存在。另外，kv的三个端口监测共 84 mb的写入，为啥在grafana中的磁盘监测写入为啥是300的写入啊，还有什么写入吗
我发现，在空表的时候前面tps可以打到1000多，然后开始下降到最后平均为600，这个时候 磁盘ioutil一直满的，磁盘写入带宽能到600mb，然后停10分钟后，再测tps稳定300，此时带宽是300mb，ioutil还是满的，即使我不压，kv的cpu还是存在
是的，但是这好像并不会导致tps很低，因为我发现，在空表的时候前面tps可以打到1000多，然后开始下降到最后平均为600，这个时候 磁盘ioutil一直满的，磁盘写入带宽能到600mb，然后停10分钟后，再测tps稳定300，此时带宽是300mb，ioutil还是满的，即使我不压，kv的cpu还是存在。另外，kv的三个端口监测共 84 mb的写入，为啥在grafana中的磁盘监测写入为啥是300的写入啊，还有什么写入吗
写热点的意思就是你的请求都在写同一个region。一个分布式系统，所有的写都集中在一个region上，那分布个啥？不就是单机的性能+额外的网络开销。还不如你单机直接装个mysql ，tps高。
所以到底啥原因呀
最初的时候肯定IO没那么高啊 ，慢慢累积的，IO不光数据写入，还有触发rocksdb的compact，你看tikv detail → rocksdb kv → compaction pending的量
这个量一般用来评估什么
查一下GC和PD节点的日志
看看gc
由于持续不对的提升自己对TiDB的认知，有时间和机会对三台物理机进行混合部署验证。进行一个简单的总结：
- 如果是一台物理机虚拟出来的多台虚拟机，他们之间的磁盘性能是公用的，在测试前需要排除其他应用抢占磁盘资源。
- 关于auto_increment修改为auto_random，没有任何提升。刚建好表，默认表只有一个region，短时间内高并发压测，即使region分裂，也是在同一个节点上。无法充分利用多台机器性能
- 预建好指定数量的region，使用auto_random，qps还是没有提升。使用的环境往往不是全新的，上面的磁盘内存有差异，每一个store的打分不一样，对应的写也将倾斜。
都是牛人
此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。