为提高效率，提问时请提供以下信息，问题描述清晰可优先响应。
观察发现，占用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 部分的信息
https://pingcap.com/docs-cn/stable/reference/garbage-collection/overview/#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 的性能
Fio 看起来 3台机器的 iops 相近，就是 TiKV 1 的 latency 有点高。可以看下以下几点：
你好， TIKV 有错误日志
三个tikv节点24小时的 disk-performance 以及 node_exporte截图见附件，并没有发现比较大的差异，0点到8点负载增加，是由于loader导入数据引起。
0103.rar (4.7 MB)
上面的错误信息，在三个tikv节点都存在
系统中并不存在热点读
./tikv-server -V
麻烦确认下各个 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 操作。
