TiKV 扩容过程中，Pending compaction bytes 一直在增加

[robert233]

【 TiDB 使用环境】

1. 生产，v4.0.12

【概述】 场景 + 问题概述

1. 单tikv的region 10w，leader在 3.6w， 扩容过程中，刚开始没有无异常，因为扩容导致了config 重新加载，配置alertmanager被覆盖，一直无告警，直到业务方反馈链接池打满，发现 rocksdb-kv pending-compaction-bytes一直在持续增加，超过soft后write stall，在超过hard之后，集群恶化.

【背景】 做过哪些操作

1. 扩容动作
   tiup cluster:v1.2.3 scale-out xxx scale-out_tikv20220820.yml -i ../ssh/tiup

2. rocksdb 线程池参数调整及soft和hard pending-compaction-bytes-limit 调整，重启之后好转，因此我们判断为compaction太慢.
   rocksdb.defaultcf.hard-pending-compaction-bytes-limit: 512G
rocksdb.defaultcf.soft-pending-compaction-bytes-limit: 512G
rocksdb.writecf.hard-pending-compaction-bytes-limit: 512G
rocksdb.writecf.soft-pending-compaction-bytes-limit: 512G
rocksdb.max-background-jobs: 12

3. 部分监控如下
   1). TiKV-Details
   

   
   
   2). TiKV-Trouble-Shooting
   
   

4. 留在最后：请教下社区大佬们，在扩容过程中pending-compaction-bytes一直在增加是正常的现象吗

[xiaohetao (Becky)]

@robert233

pending-compaction-bytes

不太正常， 你什么时候扩容的， 一般扩容建议在业务低峰或停业务的时间进行

[robert233]

扩容是在最低峰，因region太多，banlance时间会拉的特别长，有什么办法能查到pending-compaction-bytes一直增加的原因吗？
调整limit只是延后了缓写和停写的时间点，在重启集群后这个现象消失了，重启之前调整上面的参数，从系统资源使用来看，io、cpu、mem都没有到瓶顶.

[h5n1]

看下compaction reason面面板，thresd cpu中的rocksdb cpu，磁盘io性能

[robert233]

compaction reason扩容过程中没有变化，0:44开始升高是集群滚动重启，在整个数据均衡过程中，compation 变慢，write stall 是pending compaction bytes在持续增长到阈值之后出现.

[robert233]

重启之后看起来rocksdb cpu涨起来了

[robert233]

物理资源上是没有到瓶顶

[xiaohetao (Becky)]

网络呢？ kv 之间数据传输的网络I/O 情况怎么样？

[robert233]

排查过系统资源、网络，这块是没有到瓶顶

[xiaohetao (Becky)]

pending 说明

[h5n1]

0:44 开始重启集群，但是实际白天11:00 左右开始就开始累积了，write stall是玩笑20:00左右 开始出差，检查过有没有大数据量写入吗

[OnTheRoad]

如果遇到了 Write Stall，可查看 Grafana 监控上 RocksDB-kv 中的 Write Stall Reason 有哪些指标不为 0。

• 如果是由 pending compaction bytes 相关原因引起的，可将 rocksdb.max-sub-compactions 设置为 2 或者 3（该配置表示单次 compaction job 允许使用的子线程数量，TiKV 4.0 版本默认值为 3，3.0 版本默认值为 1）。

[robert233]

各位社区大佬，我阐述我的问题：
在对 tikv 扩容引发 compation pending byte 持续增长（从扩容开始），最后触发write stall，排查了物理资源，io资源和cpu资源都未到瓶颈，不知为何会影响到compaction pending bytes.

[h5n1]

https://metricstool.pingcap.com/#backup-with-dev-tools 按照这个导出下overview pd tikv-detail tidb的监控页面，要等所有面板展开 数据加载完后再导出

[TiDBer_w4puKrlI]

已上传

[h5n1]

面板没展开，大部分没数据，要等所有面板展开 数据加载完后再导出

[h5n1]

时间范围貌似不对

[dba-kit (张天师)]

建议看下这个回复，tidb很多功能都是分开设置最大允许的CPU，如果是整体负载不高，持续在某个值，很大可能是默认参数不够用导致的

[robert233]

取了2022-08-20 10:30:00-2022到2022-08-21 10:30:00的监控时间端
TiDB 监控.zip (6.5 MB)

[h5n1]

感觉像是之前一直没能到达某些条件导致不能清理一些历史数据，然后扩容时触发了某些条件，由于前面积累的比较多导致pending compact有积压，看看GC面板监控， 另外 按照实例看下是哪个tikv的compact pending积压较多