写点什么

TiDB 5.1 Write Stalls 应急文档

  • 2022 年 7 月 11 日
  • 本文字数:4379 字

    阅读完需:约 14 分钟

作者: 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


发布于: 刚刚阅读数: 2
用户头像

TiDB 社区官网:https://tidb.net/ 2021.12.15 加入

TiDB 社区干货传送门是由 TiDB 社区中布道师组委会自发组织的 TiDB 社区优质内容对外宣布的栏目,旨在加深 TiDBer 之间的交流和学习。一起构建有爱、互助、共创共建的 TiDB 社区 https://tidb.net/

评论

发布
暂无评论
TiDB 5.1 Write Stalls 应急文档_实践案例_TiDB 社区干货传送门_InfoQ写作社区