tikv时延上升,伴随region-size从平均100MB涨至30GB

部署硬件:
3台服务器6节点,每个节点部署在7.6TB的nvme盘,每台机器内存512GB,CPU: 128核

使用的是txnKv模式

现象:

时延:

二分之一的tikv region-size暴涨

紧急暂停 balance-region

PD_down_peer_region_nums大于2

top size的region信息

top3 reigon size

{"count":3,"regions":[{"id":8056302,"start_key":"3031393635623534FF2D333433342D3736FF63342D383436322DFF6261663834373038FF37363533FD41F6FEFFA404000000004300FF0000590000000000FA","end_key":"3031393635623534FF2D333433342D3736FF63342D383436322DFF6261663834373038FF37363533FD41F74DFFF200000000004900FE","epoch":{"conf_ver":77441,"version":6230},"peers":[{"role_name":"Voter","id":8056303,"store_id":1},{"role_name":"Voter","id":8056304,"store_id":3},{"role_name":"Voter","id":8056305,"store_id":2}],"leader":{"role_name":"Voter","id":8056303,"store_id":1},"cpu_usage":0,"written_bytes":54731793,"read_bytes":3532,"written_keys":385,"read_keys":10,"approximate_size":33846,"approximate_keys":371361},{"id":8064784,"start_key":"3031393635623534FF2D333433342D3736FF63342D383436322DFF6261663834373038FF37363533FD41F6FEFFA404000000004300FF00001E0000000000FA","end_key":"3031393635623534FF2D333433342D3736FF63342D383436322DFF6261663834373038FF37363533FD41F6FEFFA404000000004300FF00001F0000000000FA","epoch":{"conf_ver":77441,"version":6234},"peers":[{"role_name":"Voter","id":8064785,"store_id":1},{"role_name":"Voter","id":8064786,"store_id":3},{"role_name":"Voter","id":8064787,"store_id":2}],"leader":{"role_name":"Voter","id":8064785,"store_id":1},"cpu_usage":0,"written_bytes":131681829,"read_bytes":990,"written_keys":613,"read_keys":0,"approximate_size":33832,"approximate_keys":40985},{"id":8064640,"start_key":"3031393635623534FF2D333433342D3736FF63342D383436322DFF6261663834373038FF37363533FD41F6FEFFA404000000004300FF0000540000000000FA","end_key":"3031393635623534FF2D333433342D3736FF63342D383436322DFF6261663834373038FF37363533FD41F6FEFFA404000000004300FF0000550000000000FA","epoch":{"conf_ver":77441,"version":6231},"peers":[{"role_name":"Voter","id":8064641,"store_id":1},{"role_name":"Voter","id":8064642,"store_id":3},{"role_name":"Voter","id":8064643,"store_id":2}],"leader":{"role_name":"Voter","id":8064641,"store_id":1},"cpu_usage":0,"written_bytes":131681277,"read_bytes":1000,"written_keys":613,"read_keys":0,"approximate_size":33810,"approximate_keys":122880}]}

compact pending bytes

备注:我们在8月29日,因为balance hot region 导致时延到10秒级别,关闭了 scheduler-hot-balance-region,后续集群恢复正常

目前我们正在执行top 1 region size 的region 的compact,从15:48分开始到目前17:06分还没有结束

./tikv-ctl --host xxxx.xxxx.xxx.xxx:25200 compact -d kv --region 8056302

这个命令执行是卡住的:

./tikv-ctl --host xxxx.xxxx.xxx.xxx:25200  region-properties -r 8056302

补充后续进展:
9月24号 18:20 进行同一个物理机上的所有tikv的重启

重新执行这条命令,能正常返回结果

./tikv-ctl --host xxxx.xxxx.xxx.xxx:25200  region-properties -r 8056302

重启后最大的region size的sst文件有变化,rocksdb的日志显示有在执行compaction的


问题是什么,region size 太大?

有部署 TiDB 或者其他 gc worker 吗

没有部署tidb,也没有开启gc worker,现在的问题是事务时延越来越大,且经常出现一些region的 server is busy的错误(scheduler is busy)

18:20进行的一些操作,已经补充到原帖末尾处

那就在集群里部署一个 TiDB 试试

部署完之后,看下 TiKV-Details 里的 GC 面板

刚才回复不准确,我们是juicefs,有gc-worker

prewrite、resovle_lock、commit 99分位在1秒以上

看不出原因是什么。

采集一下监控和日志吧。

参考 【SOP 系列 22】TiDB 集群诊断信息收集 Clinic 使用指南&资料大全

他是说猛增

我们手动触发 tikv gc,将gc interval从“-3小时”缩短成“-1小时”,逐步恢复。看上去如果不能尽快gc,会导致region split失败,region size非预期的增长,最终导致transaction时延非常高,部分事务超时被drop

业务量大吗?,业务低峰期操作也是这样吗?

高峰期针对同一个key有大量的修改

围观一下
AI说拆分不依赖GC,但清理是GC负责的,如果属实的话,应该是导致Store的空间不释放,远大于实际数据量

QPS,TPS这些监控信息。有什么变化。

往业务方面考虑一下

看下 TiKV-Details 里的 GC 面板

3小时

后面要避免此类情况的出现,

另外 rawkv 不是 tidb 正常用法,所以尽可能的用 tidb 集群

1 个赞

根据 GC 面板的情况处理

  1. 分裂和compact没关系。compact是清理掉删除的数据,分裂是调整 region 的范围。
  2. 你现在的问题可能得先看看分裂为什么停了。
  3. 看看监控,pd面板里面有没有生成分裂的operator,看看pd的日志,为什么不产生分裂的operator还是被取消了。

tikv的日志在输出 region split error