tikv单节点io使用率很高,是否是因为定时任务导致

为提高效率,提问时请提供以下信息,问题描述清晰可优先响应。

  • 【TiDB 版本】:3.0.1
  • 【问题描述】:观察到我的一个tikv节点IO Util一直异常,如下是24小时的截图

观察发现,占用IO最高的是gc-worker线程。

tikv节点的磁盘IO测试,要晚上才能做,而且已经跟进了一段时间了,具体见帖子

想咨询是否有什么定时任务,导致212节点异常的高,其他两个tikv节点IO Util都正常。

若提问为性能优化、故障排查类问题,请下载脚本运行。终端输出打印结果,请务必全选并复制粘贴上传。

1、gc-worker 是垃圾回收的相关进程

2、请确认在当前的环境中是否做过大数据量的 drop 、truncate 或者 DML 操作。如果有,则可参考下述链接,并确认下:

1)select * from mysql.tidb 看下 gc 相关的内容

2)查看 tidb 监控中 gc 部分的信息

3)查看 tikv 监控中 gc 部分的信息

在系统中,并没有做个大量的truncate、DDL、DROP操作

1 查询结果

2 24小时的tidb GC信息

3 24小时的tikv GC信息

看监控 gc 任务是正常的,并且使用 iotop 查询出来的结果 gc-worker 只占用了 16% 左右,你那里可以看下其他 tikv 节点的 iotop 中 gc-worker 是怎样的,比较下~

这个是疑问节点212的iostat情况,几乎处于100,然后iotop看,只有gc worker占用大

另外两个节点iotop情况 tikv2

tikv3

但是两个tikv的iostat很低 tikv2

tikv3

主要就是想搞清楚tikv1的IO Util 100%,可能是什么原因,会不会导致整个tidb集群性能下降

1、从上述信息看,节点 212 的流量稍低于其他节点,建议查看下该服务器磁盘 io 能力和其他服务器是否有差异

2、如果是一台 tikv 服务器的性能低于其他服务器,一定程度上会影响整个 tikv 的性能

你好,三个tikv节点fio压测结果fio压测.rar (6.5 KB)

Fio 看起来 3台机器的 iops 相近,就是 TiKV 1 的 latency 有点高。可以看下以下几点:

  1. TiKV 1 的 日志有没有异常
  2. disk-performance 以及 node_exporte 的监控对比其他的机器有没有监控项的异常。

你好, TIKV 有错误日志

三个tikv节点24小时的 disk-performance 以及 node_exporte截图见附件,并没有发现比较大的差异,0点到8点负载增加,是由于loader导入数据引起。

0103.rar (4.7 MB)

上面的错误信息,在三个tikv节点都存在

系统中并不存在热点读

image

  1. 导出一份 TiKV 的监控信息用于分析。
  2. 麻烦确认 TiKV 1 节点的配置信息是否与 其他节点不一致 , 以及确认 TiKV 1 的版本信息是否与另外两个节点一致 ./tikv-server -V

您好, 1 tikv detail24小时grafana监控信息 tikv_detail_2.rar (4.3 MB) tikv_detail_1.rar (2.6 MB)

2 tikv版本

麻烦确认下各个 TiKV 节点的配置是否一致。

都是一致的,服务器规格为阿里云ecs.g5.2xlarge,8C32G,数据盘2T的ESSD

从 tikv1 的 node exporter 看到 14:00-18:00 期间的 iops 和 io 吞吐量都很低,ioutil 持续在 100%;

00:00 开始 io 吞吐量上涨到 200MB+,磁盘读写延迟略有上涨,与 fio 测试结果对比性能表现符合预期;

ioutil 是单个磁盘 io 繁忙度的度量,对于后端有多块磁盘组成的虚拟 SSD 云盘意义不大,并不能说明 ioutil 到了 100% 就表示磁盘已经到达最大性能,如果对 ioutil 显示仍有疑问,建议进一步咨询云厂商或系统管理人员。

观察到 00:00-08:00 负载上升期间,tikv1 的 disk io size 明显要高于另外两个 tikv,可能和 tikv1 磁盘的 iops 较低有关

一般如果 iops 较高的磁盘,处理的快可能 disk io size 会比较小,如果磁盘本身延迟高,但是吞吐还行,上层的写入可能就攒批了,会导致 disk io size 比较大

请问目录{deploy}/data/db/目录下,有13W的文件,对性能有没有影响呢

之前这个帖子的测试结果显示 tikv1 的读 iops 最低,麻烦用之前的 fio 命令对比测一下 bs=32k -rw= randwrite 时的 iops,看看 tikv1 的表现

sst 文件的数量不会影响性能,只有在 rocksdb 需要从磁盘读或向磁盘写数据时,涉及到相关的 sst 文件,才会进行磁盘 IO 操作。