作者： mydb 原文来源：https://tidb.net/blog/ac7174dd

靳献旗 ｜ 汽车之家 DBA

1. 背景

stall 是 rocksdb 的一种流控机制，当 flush/compaction 赶不上 write rate 的速度时，rocksdb 会降低 write rate，甚至停写。而 TiDB 集群中的 TiKV 组件是基于 rocksdb 开发的，因此 TiDB 集群出现 write stall 时则会表现出：集群写入变慢，甚至写入阻塞，影响业务。

笔者最近处理过几起 write stall 的问题，既有 4.0 版本，也有 5.1 版本，但是在这两个大版本上，write stall 相关日志、监控、命令不太相同，为了避免出现问题时，临时去查文档和命令，于是编写了本文档。文本主要基于 5.1.4 版本编写，部分内容会在备注中提一下 4.0 版本中的不同点。

2. 常见 write stall 场景

发生 write stall 常见的三种场景是：

• Memtable 文件数量过多，且达到阀值写入到 RocksDB 的数据首先会记录到 WAL 日志里面，然后会插入到 memtable 里面，当 memtable 的大小到达了 write-buffer-size 限定的大小的时候，当前的 memtable 会变成只读的，然后生成一个新的 memtable 接收新的写入。只读的 memtable 会被 RocksDB 的 flush 线程 (flush 线程的最大个数由参数 max-background-flushes 控制) flush 到磁盘，成为 level0 的一个 sst 文件。当 flush 线程忙不过来或者磁盘写入太慢，导致等待 flush 到磁盘的 memtable 的数量到达 max-write-buffer-number 限定的个数的时候，这时就会发生 write stall 。

• L0 层 SST 文件数量过多，且达到阀值当 level0 的 sst 文件个数到达 level0-slowdown-writes-trigger 指定的个数时，RocksDB 会尝试减慢写入的速度。因为 level0 的 sst 太多会导致 RocksDB 的读放大上升。当 level0 的 sst 文件个数到达 level0-stop-writes-trigger 指定的个数时，则会出现 write stall。

• L1 ~ Ln 层待 Compaction 的 SST 文件的大小过大，并且达到阀值当 level1 的数据量大小达到 max-bytes-for-level-base 限定的值的时候，会触发 level1 的 sst 和 level2 中有 overlap 的 sst 进行 compaction，其它 L 层的文件也会在达到阀值时往下一层 compaction 。如果从 L1 到 Ln 层合并压缩太慢，导致待 compaction 的 SST 文件的大小过大时 (达到阀值) 则会出现 write stall。

为了便于理解，这里借用一下 PingCAP Education 【302 TiDB 高级系统管理】视频课程里的一张图片 (下图中 L 层上标记的大小随着 TiDB 集群版本的不同而不同，这里主要为了说明原理)：

3. 出现 write stall 阀值

针对上一节出现的三种场景的 write stall 的阀值总结如下：

| 场景 | write stall slow 阀值 | write stall stop 阀值 | 缓解参数 || :- | :——————————————————————————————————————- | :——————————————————————————————————————- | :——————————————————————————————————————————————————————————————————————————————————————– || 1 | 4(max-write-buffer-number) | 5(max-write-buffer-number) | write-buffer-sizemax-write-buffer-numbermax-background-flushes || 2 | 20(level0-slowdown-writes-trigger) | 36(level0-stop-writes-trigger) | level0-slowdown-writes-triggerlevel0-stop-writes-triggerrocksdb.max-sub-compactions || 3 | 192G(rocksdb.defaultcf.soft-pending-compaction-bytes-limit)192G(rocksdb.writecf.soft-pending-compaction-bytes-limit) | 256G(rocksdb.defaultcf.hard-pending-compaction-bytes-limit)256G(rocksdb.writecf.hard-pending-compaction-bytes-limit) | rocksdb.defaultcf.soft-pending-compaction-bytes-limitrocksdb.defaultcf.hard-pending-compaction-bytes-limitrocksdb.writecf.soft-pending-compaction-bytes-limitrocksdb.writecf.hard-pending-compaction-bytes-limitrocksdb.rate-bytes-per-secrocksdb.max-background-jobs |

说明：

• 场景表示第 2 节提到的三种 write stall 场景

• write stall slow 阀值表示达到此阀值之后，TiDB 开始写入变慢

• write stall stop 阀值表示达到此阀值之后，TiDB 开始无法写入

• 缓解参数表示当发生 write stall 时可能需要调整的参数

4. 判断是否出现了 write stall

判断 TiDB 集群是否出现了 write stall 可以参考如下方法：

(1) 查看集群是否出现了 server is busy 及原因

tikv-details – errors – server is busy     

(2) 查看引起 write stall 的原因

tikv-details – rocksdb-kv – write stall reason               

说明：4.0 版本在 tikv-details -- rocksdb-raft -- write stall reason  

(3) 是否有大量数据处于 compation pending 状态 tikv-detail – rocksdb-kv – compaction pending bytes 

说明：4.0 版本在 tikv-details -- rocksdb-raft -- compaction pending bytes

(4) 分析 tikv 日志辅助判断 grep ‘Stalling writes’ /data3/tikv20173/data/rocksdb.info   

说明：(1) 4.0 版本 write stall 日志文件位置在 /data3/tikv20173/data/raft 目录下，以 LOG 开头的文件。(2) 出现 write stall 场景 1 日志类似如下，日常运维过程中笔者没遇到过这种场景，下面日志是截取自网络[default] Stalling writes because we have 4 immutable memtables (waiting for flush)(3) 出现 write stall 场景 2 日志类似如下，下面日志是截取自真实生产环境[default] Stalling writes because we have 20 level-0 files rate 5368709120(4) 出现 write stall 场景 3 日志类似如下，下面日志是截取自真实生产环境[default] Stalling writes because of estimated pending compaction bytes 130562502580 rate 8589932

5. 处理方法

这里需要说明一下，当出现 write stall 时，我们还要分析一下是因为磁盘 IO 压力太大导致的，还是某些 tikv 并发刷盘参数太小导致的。

如果磁盘 IO 压力和 CPU 压力不大，适当调整第 3 节表格中的 tikv 并发刷盘参数可以解决 write stall 的问题。但是如果磁盘 IO 压力和 CPU 压力大，说明 write stall 的本质原因是磁盘 IO 跟不上导致的，调整某些参数阀值只能缓解 write stall ，无法从根本上解决问题，此时可以考虑业务端限流或者集群扩容。

还有一点需要说明一下，目前我知道的修改 TiKV 参数的方法有以下三种：

• 修改集群拓扑文件，需要重启集群这种是最原始的方式，需要 reload 集群，速度慢点

• 通过 tikv-ctl 在线修改支持在线修改，本文第 3 节列举的 tikv 参数只有一个 max-sub-compactions 不支持在线修改，其它均支持在线修改，速度较快

• 通过 SQL 在线修改支持在线修改，速度较快，具体支持哪些参数可以参考官方文档，文末参考文档中给出了链接

对于 tikv 参数，如果可以在线修改，建议使用 tikv-ctl 在线修改，无法在线修改的，只能通过修改配置文件，然后 reload 的集群方式修改。将来，通过 SQL 语句在线修改的方法成为正式特性之后，再建议大家使用。

5.1Memtable 文件数量过多

对于 Memtable 文件数量过多导致的 write stall 问题，可调整如下参数进行缓解：

说明：

官方文档中 max-background-flushes 的默认值写的是 2 ，应该是错了。

针对上面表格参数，下面给出具体的修改示例，其它参数都可以参考这种方式修改：

• 通过 SQL 在线修改这里以修改参数 write-buffer-size 为例

• 通过 tikv-ctl 在线修改这里以修改参数 rocksdb.max-background-flushes 为例

备注：

如果你要修改的值是文件大小则需要带上单位，如下所示./tikv-ctl --host=192.168.1.1:20161 modify-tikv-config -n rocksdb.defaultcf.soft-pending-compaction-bytes-limit -v 192GB

• 修改集群拓扑文件这里以修改参数 max-background-flushes 为例

(1) 查看当前配置

show config where type='tikv' and name like '%max-background-flushes%';

(2) 修改集群拓扑文件

server_configs:  tikv:    rocksdb.max-background-flushes: 4   #增加这一行配置

(3) 集群 reload

tiup cluster reload jxs_cluster_yz -R tikv

(4) 验证配置在线查看配置是否修改

show config where type='tikv' and name like '%max-background-flushes%';

也可以登录 tikv 实例服务器查看配置文件是否多了下面这行配置

[rocksdb]max-background-flushes = 4

5.2L0 层 SST 文件数量过多

可调参数如下

调整步骤请参考 5.1 节。

5.3L1 ~ Ln 层待 compation 的 SST 文件过大

可调参数如下

调整步骤请参考 5.1 节。

6. 注意事项

目前官方不建议使用 SQL 语句在线调整 TiKV 参数，属于实验特性，详情请见官方文档

https://docs.pingcap.com/zh/tidb/v5.1/dynamic-config#%E5%9C%A8%E7%BA%BF%E4%BF%AE%E6%94%B9-tikv-%E9%85%8D%E7%BD%AE

【参考文章】

PingCAP Education 305 视频课程

https://docs.pingcap.com/zh/tidb/v5.1/tune-tikv-memory-performance#%E5%8F%82%E6%95%B0%E8%AF%B4%E6%98%8E

https://docs.pingcap.com/zh/tidb/v5.1/tikv-configuration-file#max-background-flushes

https://docs.pingcap.com/zh/tidb/stable/tidb-troubleshooting-map#43-%E5%AE%A2%E6%88%B7%E7%AB%AF%E6%8A%A5-server-is-busy-%E9%94%99%E8%AF%AF

https://docs.pingcap.com/zh/tidb/v5.1/dynamic-config#%E5%9C%A8%E7%BA%BF%E4%BF%AE%E6%94%B9-tikv-%E9%85%8D%E7%BD%AE