sysbench 压测TIDB update性能结束后，IO一直很高

[changeflyhigh]

为提高效率，提问时请提供以下信息，问题描述清晰可优先响应。

• 【TiDB 版本】：v4.0.0
• 【问题描述】：sysbench 压测TIDB update性能停止后, tikv磁盘IO高负载持续一个小时, 太长时间了. 但是压测 insert 不会这样子的

# iostat -cdmx 2 vdb

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           1.31    0.00    0.69    2.22    0.00   95.77

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vdb               0.00  1212.00   22.50 1799.50     0.82    12.41    14.87     0.96    0.52    0.69    0.52   0.48  87.80

[来了老弟]

可否上传下 tikv-detail 监控的完整截图，时间对应在 io 高的时间区间，
将一下 sql 的执行结果上传下：select * from mysql.tidb where variable_name like '%gc%';

[changeflyhigh]

[changeflyhigh]

[changeflyhigh]

[来了老弟]

看下对应时间点的 tikv-detail gc 的监控，是否能与其对应

[changeflyhigh]

[changeflyhigh]

从时间上来看, 磁盘高IO期间和GC 的时间段是一致的

[来了老弟]

hi
对应的 gc worker cpu 的监控可否上传再看下

[changeflyhigh]

是指这个吗?

[来了老弟]

tikv detail 面板中 gc 信息

[changeflyhigh]

我已经截完了, 没有其他了

[来了老弟]

update 压测结束，数据量较大，tikv 需要 gc 和 compaction sst file 此期间，io 可能会比较高。预期

[changeflyhigh]

gc操作能通过调优 加速吗? 一个小时太长了

[来了老弟]

目前 io 已经成为瓶颈，调大线程并不能解决这个问题，看下可否升级硬件，或者关注下业务上的反馈，看是否有影响

[changeflyhigh]

好的, 感谢回复!

[来了老弟]