【 TiDB 使用环境】生产环境
【 TiDB 版本】6.1.6
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
tidb 经常查询抖动，抖动时一般伴随下面这种情况
看一下其中一个比较慢的时间点 指向的是一个tikv，从这个tikv日志来看 ，raft相关同步卡顿导致慢了
raft相关延迟确实比较高
然后调整过 raftstore.store-io-pool-size 相关参数 并没有效果
观察到两个奇怪现象
1.tikv的black cache hit很低，跟其他集群表现不一样，如下图
2.raft cpu持续抖动，sql出现抖动和这个cpu抖动时间相对比较吻合 10分钟抖动一次
关于10分钟有波动这个，尝试停止了raft和rocksdb的10分钟一次的统计信息，还有其他的参数都没有效果
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】
我的第一反应是，你说的IO是不是满了。看看磁盘读写
TiDB 调度过程中会占用 I/O、Network、CPU、Memory 等资源，若不对调度的任务进行控制，QPS 和延时会因为资源被抢占而出现性能抖动问题。通过以下几项的优化，长期测试 72 小时，衡量 Sysbench TPS 抖动标准差的值从 11.09% 降低到 3.36%。
store-limit 配置项设置过大引起的调度，引入一套新的调度算分公式并通过 region-score-formula-version = v2 配置项启用新的调度算分公式 #3269
enable-cross-table-merge = true 开启跨 Region 合并功能，减少空 Region 的数量 #3129
rate-limiter-auto-tuned 配置项开启此功能后，延迟抖动比未开启此功能时的抖动大幅减少 #18011
gc.enable-compaction-filter = true 开启 #18009
bg_task_io_rate_limit 配置项开启限制压缩或整理数据 I/O 资源。TiDB 调度过程中会占用 I/O、网络、CPU、内存等资源，若不对调度的任务进行控制，QPS 和延时会因为资源被抢占而出现性能抖动问题。
通过以下几项的优化，测试 8 小时，TPC-C 测试中 tpm-C 抖动标准差的值小于等于 2%。
当节点的总容量总是在系统设置的水位线附近波动或者 store-limit 配置项设置过大时，为满足容量负载的设计，系统会频繁地将 Region 调度到其他节点，甚至还会调度到原来的节点，调度过程中会占用 I/O、网络、CPU、内存等资源，引起性能抖动问题，但这类调度其实意义不大。
为缓解此问题，PD 引入了一套新的调度算分公式并默认开启，可通过 region-score-formula-version = v1 配置项切换回之前的调度算分公式。
在 5.0 之前，TiDB 默认关闭跨表合并 Region 的功能。从 5.0 起，TiDB 默认开启跨表合并 Region 功能，减少空 Region 的数量，降低系统的网络、内存、CPU 的开销。你可以通过修改 schedule.enable-cross-table-merge 配置项关闭此功能。
在 5.0 之前，为了平衡后台任务与前端的数据读写对 I/O 资源的争抢，自动调整 Compaction 的速度这个功能默认是关闭的；从 5.0 起，TiDB 默认开启此功能并优化调整算法，开启之后延迟抖动比未开启此功能时的抖动大幅减少。
你可以通过修改 rate-limiter-auto-tuned 配置项关闭此功能。
TiDB 在进行垃圾回收和数据 Compaction 时，分区会占用 CPU、I/O 资源，系统执行这两个任务过程中存在数据重叠。
GC Compaction Filter 特性将这两个任务合并在同一个任务中完成，减少对 CPU、I/O 资源的占用。系统默认开启此功能，你可以通过设置 gc.enable-compaction-filter = false 关闭此功能。
该特性能缓解后台任务与前端的数据读写对 I/O 资源的争抢。
系统默认关闭该特性，你可以通过 bg_task_io_rate_limit 配置项开启限制压缩或整理数据 I/O 资源。
吞吐量很小，就dm做数据同步几个表，然后简单查询，偶尔会卡顿，使用率也很低，怀疑还是跟raft这里cpu抖动影响
两个猜想：
配置不足，满足不了场景使用
突发的热点写入，导致了流控保护，看起来就是响应很慢
纯粹只能猜测… 
这些都有做过优化的哈
有规律的10分钟跳一次的话，我会重点怀疑gc引起的。
你可以查看一下和gc 的运行时间是否能对的上。
如果确认是gc造成的这个tikv的写入慢，还是重点怀疑是不是磁盘有什么问题会比较合理。
因为，其他tikv也会在同一时间有gc但不会像这个tikv一样出问题罢了。
对比这个tikv和其他tikv的ops和写入字节量，如果这些都无明显差异，可能更像是单纯就是这个磁盘慢了。
嗯嗯 开始怀疑过磁盘，但是其他tikv也有 只是当时是这个tikv 其他时间段是其他tikv ，所以不应该是磁盘有问题
gc时间之前也怀疑过，但是没有进行调整，
把gc时间调整一下，看看是不是gc引发的
CPU是什么类型的，有没有关闭节能模式？ 看看网络监控 可以从black exporter、nodeexporter里看
跟gc关系也不大哈 调整了 任然有问题
tikv_gc_run_interval
tikv_gc_life_time
两个都改了吗，和第一个关系大
https://docs.pingcap.com/zh/tidb/stable/latency-breakdown#异步写入
avg Storage Async Write Duration = avg Store Duration + avg Apply Duration
上面这几个文档的排查思路还是挺清晰的，我觉得你可以好好对比排查一下。
顺便看看这个图，排查一下到底是那个环节慢了。
这种症状基本上与IO有关系。
解决了吗
啥问题
一抖就是一个大写发生
