为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：
【TiDB 版本】
tidb Version: v4.0.0
【问题描述】
3个节点每天跑定时任务录入数据并不是很大，但是io会冲满，最近几天修改了tikv压缩率， store-pool-size和开启hibernate-regions配置之后，磁盘io一直都是满的状态，写入很慢，3个tikv的硬盘都是SSD，之前做过iops测试参数都是通过的,希望大佬们指点一下如何处理
查看tikv日志发现有大量 alloc timestamp failed, lease expired 错误
pd 日志 时有we haven’t synced timestamp ok, wait and retry错误
监控，日志文件以及修改的配置如下
tidb 配置文件
tikv iotop
tikv监控及日志
若提问为性能优化、故障排查类问题，请下载脚本运行。终端输出的打印结果，请务必全选并复制粘贴上传。
看了下 IOPS 也不高，但是 util 比较高，但是磁盘的 latency 是 ms 级别的，这个是比较高的
升级的话可以选择在线升级，那样只是对业务 duration 会有一些抖动，并不会有中断的情况，不过具体可以在测试环境先测试下下升级对业务的影响：【SOP 系列 16】4.0 线上集群升级 5.0
写入慢的情况，可以参考排查文档看看：TiDB 写入慢流程排查系列（一）— 前言 - #8
这里是3台节点按照tidb文档的iops测试
91_fio_randread_write_test.json (7.1 KB) 92_fio_randread_write_test.json (7.1 KB) 94_fio_randread_write_test.json (7.1 KB)
好的，但是先看看io的问题
请问这个是云主机还是物理机？是云上 SSD 磁盘吗？
看 iotop 的结果，最高的占用 io 的进程是 tikv 的 gc-worker 进程，可以看下 IO 高的周期与 GC 的周期是否是一致的。如果一致的话，可以调整一下 GC 的配置二次确认是 GC 的影响。
https://docs.pingcap.com/zh/tidb/stable/garbage-collection-configuration#gc-配置
因为提供的监控时间比较长，时间粒度比较粗，所以我这边不太好确认，需要你确认一下。
你好，我这里是esxi的虚拟机，ssd都是挂载的单个物理盘。
gc的配置我看了默认配置感觉挺适合的，不确定要改哪一项。
我先升级tidb 版本看看
怀疑 GC 是怀疑 GC 的周期和 IO 高的周期相同，那样的话可以调整 GC 的 interval 时间来改变 GC 的周期，看下 IO 高的周期是否随之变化，如果是的话，那就证明是 GC 的影响。
先升级 TiDB 版本也可以。
好的，我先观察一下再反馈
辛苦
