tidb写入为什么这么慢，怀疑是磁盘问题，换了ssd也是同样结果，求大佬帮忙看下

🪐 TiDB 技术问题
,
21

之前用的机械，后面复现问题用的wsl,wsl在ssd上，samsung ssd980 1T，1pd 1tidb 3kv 和监控

22

建议修改一下sbtest的表结构，改成打散结构，参考这里
https://docs.pingcap.com/zh/tidb/stable/troubleshoot-hot-spot-issues#使用-auto_random-处理自增主键热点表

1 个赞
23

这图看着就是写热点啊。

https://docs.pingcap.com/zh/tidb/stable/troubleshoot-hot-spot-issues#确定存在热点问题

24

是的，但是这好像并不会导致tps很低，因为我发现，在空表的时候前面tps可以打到1000多，然后开始下降到最后平均为600，这个时候 磁盘ioutil一直满的，磁盘写入带宽能到600mb，然后停10分钟后，再测tps稳定300，此时带宽是300mb，ioutil还是满的，即使我不压，kv的cpu还是存在。另外，kv的三个端口监测共 84 mb的写入，为啥在grafana中的磁盘监测写入为啥是300的写入啊，还有什么写入吗

25

我发现，在空表的时候前面tps可以打到1000多，然后开始下降到最后平均为600，这个时候 磁盘ioutil一直满的，磁盘写入带宽能到600mb，然后停10分钟后，再测tps稳定300，此时带宽是300mb，ioutil还是满的，即使我不压，kv的cpu还是存在

26

是的，但是这好像并不会导致tps很低，因为我发现，在空表的时候前面tps可以打到1000多，然后开始下降到最后平均为600，这个时候 磁盘ioutil一直满的，磁盘写入带宽能到600mb，然后停10分钟后，再测tps稳定300，此时带宽是300mb，ioutil还是满的，即使我不压，kv的cpu还是存在。另外，kv的三个端口监测共 84 mb的写入，为啥在grafana中的磁盘监测写入为啥是300的写入啊，还有什么写入吗

27

写热点的意思就是你的请求都在写同一个region。一个分布式系统，所有的写都集中在一个region上，那分布个啥？不就是单机的性能+额外的网络开销。还不如你单机直接装个mysql ，tps高。

28

所以到底啥原因呀

29

最初的时候肯定IO没那么高啊 ，慢慢累积的，IO不光数据写入，还有触发rocksdb的compact，你看tikv detail → rocksdb kv → compaction pending的量

30

这个量一般用来评估什么

31

查一下GC和PD节点的日志

32

https://zhuanlan.zhihu.com/p/437151725

看这个。

33

看看gc

34

由于持续不对的提升自己对TiDB的认知，有时间和机会对三台物理机进行混合部署验证。进行一个简单的总结：

  1. 如果是一台物理机虚拟出来的多台虚拟机，他们之间的磁盘性能是公用的，在测试前需要排除其他应用抢占磁盘资源。
  2. 关于auto_increment修改为auto_random，没有任何提升。刚建好表，默认表只有一个region，短时间内高并发压测，即使region分裂，也是在同一个节点上。无法充分利用多台机器性能
  3. 预建好指定数量的region，使用auto_random，qps还是没有提升。使用的环境往往不是全新的，上面的磁盘内存有差异，每一个store的打分不一样，对应的写也将倾斜。
35

都是牛人