【 TiDB 使用环境】生产环境
【 TiDB 版本】v7.1.2
【遇到的问题：问题现象及影响】 TIDB v7.1.2 在全量灌入数据阶段每2个小时出现一次写陡降到0，从TIDB慢查询中看一条简单的写操作都能到几秒级别，同时这期间是没有读SQL的，这种问题如何定位，可以提供一些排查问题的思路【不用考虑硬件问题和迁移任务的问题】
【附件：截图/日志/监控】
TIDB 影响行数监控：
TIKV 监控信息：
看这些监控图，问题出现时都是比较有规律的间隔，应该要重点查看一下 tikv的情况，尤其是 GC。
先看看 GC 触发间隔是不是每2小时一次。
通过 dashboard 看下有没有热点
SQL响应时间图呢，是否有慢SQL，活动会话图
降低这么厉害应该有日志会写点什么，把tidb tikv pd这个时间点日志都看看
gc层分析过了，不是这个问题
没有读请求
这个慢SQL重点分析一下，从Dashboard里可以查看到具体的执行慢的环节
https://metricstool.pingcap.net/
按这个export 导出下 overview/ tidb/tikv-detial/node-exporter/pD的快照看看
导出监控步骤：
打开监控面板，选择监控时间，一定要展开所有面板，等数据加载完(先按 d 再按 E 可将所有 Rows 的 Panels 打开，需等待一段时间待页面加载完成）
参考https://metricstool.pingcap.net export 导出 Grafana 数据为快照
我参考一下，谢谢
https://docs.pingcap.com/zh/tidb/stable/tikv-configuration-file#l0-files-threshold
l0-files-threshold
- 当 KvDB 的 L0 文件个数达到该阈值时，流控机制开始工作。当
enable的值为true时，会覆盖rocksdb.(defaultcf|writecf|lockcf).level0-slowdown-writes-trigger的配置。- 默认值：20
soft-pending-compaction-bytes-limit
- 当 KvDB 的 pending compaction bytes 达到该阈值时，流控机制开始拒绝部分写入请求，报错
ServerIsBusy。当enable的值为true时，会覆盖rocksdb.(defaultcf|writecf|lockcf).soft-pending-compaction-bytes-limit的配置。- 默认值：“192GB”
l0文件太多（超过默认值20），pending compaction bytes超过200g（图里面都能到500g），都触发tikv流控了。
tidb日志里面估计能看到ServerIsBusy。
https://docs.pingcap.com/zh/tidb/stable/rocksdb-overview#writestall
建议看一下，文档中关于writestall的内容，调整一下参数。
2 个赞
兄弟跟我想的一样，确实触发WRITE STALL了，哈哈，辛苦你了
1 个赞
其实一看你监控图给的这么精准，我就觉得，你心里应该是有谱了。 
这块的经验确实比较少，所以还是请教一下，哈哈
没有读，那就是写入问题了，写入无非就是IO瓶颈，tidb server层分析慢，TIKV的rocksdb写入慢，Raftstore 线程池堆积，pd调度出问题了之类的吧，挨个排查一遍呗
Raftstore 线程池是 TiKV 最为复杂的一个线程池，默认大小（raftstore.store-pool-size）为 2，所有的写请求都会先在 store 线程 fsync 的方式写入 RocksDB （除非手动将 raftstore.sync-log 设置为 true；而 raftstore.sync-log 设置为 false，可以提升一部分写性能，但也会造成数据丢失的可能）。由于存在 IO，store 线程理论上不可能达到 100% 的 CPU。为了尽可能地减少写磁盘次数，将多个写请求攒在一起写入 RocksDB，最好控制其 CPU 使用在 40% ～ 60% 。千万不要为了提升写性能盲目增大 store 线程池大小，这样可能反而会适得其反，增加了磁盘负担让性能变差。
分析的很透彻，牛
方便发下 tikv-detail → rocksdb → write stall reason的截图不
发一下截图看看
