Unified Read Pool CPU一直打满

🪐 TiDB 技术问题
1

【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】V5.4.0
【遇到的问题】
1、Unified Read Pool CPU 设置为10，5个tikv节点基本都一直打满1000%

image
image1553×797 190 KB

2、Running tasks每个节点最多的时候2000+，本来想试试 设置 tidb_enable_paging参数ON试试。结果参数show variables like ‘%tidb_enable_paging%’;没有找到
image
image918×608 56.1 KB

【复现路径】做过哪些操作出现的问题
【问题现象及影响】
1、整个库查询都变慢了，大部分查询都Coprocessor 累计执行耗时长
image
image529×502 8.65 KB

2、tidb_enable_paging设置不了
【附件】

请提供各个组件的 version 信息，如 cdc/tikv，可通过执行 cdc version/tikv-server --version 获取。

2

gRPC coprocessor

image
image1856×899 347 KB

3

max-thread-count可以调大点，你这扫描数据扫的太厉害了

4

感觉不太对，这个不应该一直打满，压力其实还好，coprocessor pool分开改成12基本也是12打满

image
image930×274 30.5 KB

5

用 PingCAP MetricsTool提供一下详细的tikv监控数据吧

6

抱歉，感觉还是不敢导数据传出来:sleepy:

7

Unified read pool 线程池是 TiKV 的另一个线程池，默认配置(readpool.unified.max-thread-count)大小为机器 CPU 数的 80%。由 Coprocessor 线程池与 Storage Read Pool 合并而来，所有的读取请求包括 kv get、kv batch get、raw kv get、coprocessor 等都会在这个线程池中执行。Unified read pool CPU 为 Unified read pool 线程的 CPU 使用率，通常代表读取的负载。

慢SQL多吗？对业务有影响？

8

现在恢复正常查询速度了，没啥慢sql。感觉是持续一晚上就会出现变慢情况了，现在分开了read pool， Coprocessor 线程池设置为12，但是还是打满的情况，对比其他集群偶尔才25%，现在一直1200%

9

因为改了coprocessor池12，重启了所有tikv节点恢复的

10

cpu都打满了，要是关闭unify-read-pool会不会还好点