tidb 4.0-rc tikv 节点的数据盘 IO 使用率 100%

🪐 TiDB 技术问题 部署&运维管理
23

1、io util 使用率上升和业务写入的特性有一定的正相关性，从上面的 DM 的配置，以及磁盘的使用带宽看到用量是比较大的在 140+M,并且存在使用量突然增长的情况，这个可以通过 DM 同步的 binlog 数量来确认下。

2、上面提到的 2.1 不会这样，但是 4.0 rc 会这样，请问下是在同样的 DM 7 个 task 并且相同 thread 的配置以及业务压力下，表现不一样吗？

3、从 3.0 开始 tidb 对写入进行了相关优化，比如，将 raftstore 和 apply 进行分拆

综上，建议先调小 task 的 syncer 的同步线程后，再观察下。

24

1.以我们源头数据库的修改，大约 1 小时产生 1GB 的 binlog，就算复制成三份全落到一个 tikv，也只是 3GB，也就是一个 TiKV 一小时以内只有不到 10GB 的 IO，相当小的.

10GB / 3600s，每秒平均在 3MB 的写入.

从 iotop 看，io 最高的是 raftstore。可能 raft 协议那里实现有点啥问题，或者默认配置不合适——按说我们的数据量不大，raft 那里默认配置可以的

2 2.1的同步任务还要多一些，写入压力也比新集群大。

3 调小task的syncer 同步进程，会导致，task在binlog新增量较大的情况下，task任务延迟。体现就是binlog file gap between relay and syncer 值会大于3，业务实时查询，不能忍受。

25

补一幅监控图。

关闭dm task前后变化。按道理，我们的写入速度 比老集群要低，但这里会到100%。对比老集群只有 20~40%

image
image1650×775 321 KB

26
  1. 建议确认所有硬件和软件都是一致的，包括硬盘型号，操作系统版本等是否一致
  2. 从iotop 里看到是 jbd2 进程 消耗多， 请找你们操作系统管理员帮忙排查下 jbd2的问题，多谢。
27

确定一致。

jbd2 进程 在集群停止数据写入的时候，是正常的。

28

如果都没有写入，jdb2有可能也会降低。 你可以测试安装mysql或者其他业务来压测，看看当IO上来的时候，jdb2会升高吗？

29

也是诚心诚意 和你们反馈问题

如果你们复现不了，我没话说…

30
  1. 关于系统 bug 引起 jdb2 的问题，麻烦可以进行一下排查，因为 jbd2引起IO高的问题的表象就是会随着其他应用 io 的升高而升高的。
  2. 如果确认不同版本的读写压力负载一样的话。麻烦检查一下两个版本的 TiKV 的设置，如两个版本的 block-cache，memtable ， rocksdb 每一层的压缩算法的设置是否有造成的两个版本的 IO 不一样
31

请问这个有结论吗?
我们貌似也碰到类似问题,我是 4.0.4
明明写入的东西都不多.但是tikv的io非常高,而且也是这个jdb2涨的飞快
io uitl基本都在 90%
观察disk write 每秒都有 100M+
但是总的磁盘占用就没涨~~~

32

请检查tikv节点的RAID卡是有电池，是否开启了缓存，机械盘必须要打开缓存。

33

:slightly_smiling_face: