影响coprocessor的相关参数及意义

db_user · 2023 年5 月 12 日 10:13

【 TiDB 使用环境】生产环境 /测试/ Poc 生产
【 TiDB 版本】v4.0.13
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】

目前情况是一个定时任务会扫描索引30万个key,并发几十个，会造成另一个查询的rpc时间变长

想问下
1.readpool.coprocessor.low-concurrency的意义是否代表是对于非点查的情况只能同时有25个cop
2.如何查看当前非点查的cop线程数量情况
3.遇到cop速度慢的时候是调优readpool.coprocessor.low-concurrency更有用些还是调优tidb_index_lookup_concurrency
tidb_index_lookup_join_concurrency
tidb_index_lookup_size
tidb_index_serial_scan_concurrency
等参数更有用些

期待大佬们解答

人如其名 · 2023 年5 月 13 日 12:13

个人理解：
1、同一个时刻只能25个正在干活，通过测试推测并不是执行完一个task再执行下一个，应该是分配时间片的。一个task就算没执行完也会让出CPU让下一个task干活。但是不清楚为何max-tasks-per-worker-low单线程层面设置任务积压，而不是整个low-concurrency线程池维度的积压。如果针对线程层面做积压，不知道会不会有部分线程任务“轻”比如只做扫描，不做聚合等执行任务较快，其它可能执行任务较重。从而导致任务执行在不同线程上执行不均匀。
2、在非使用统一unified_read_pool情况下（比如你单独设置了readpool.coprocessor.low-concurrency），应该可以参考这个：

根据配置线程数然后看比例。
3、我认为调整tidb层面的并发只能减少同一个时刻对tikv的copTask请求量，但是整体会变慢。重点还是在tikv本身上。并发多任务重（扫描多个key或者聚合等）的copTask可能会占用太多时间片，导致整体响应缓慢。在CPU充足的情况下调整readpool.coprocessor.low-concurrency更加有效。但是这个根本上来讲怀疑还是扫描数据较慢导致，这块更期待官方优化，比如共享扫描，任务下推到更低的“rocksDB存储层，进一步下压”等，但是我估计难度很大，毕竟需要自己来设计存储。

人如其名 · 2023 年5 月 13 日 12:38

我自己测试了下，不使用readpool.unified统一线程池的话，好像放到了normal级别上，不是low级别上，不过我是7.0版本的。

db_user · 2023 年5 月 14 日 00:06

确实，我感觉主要是cop的影响，而且因为我cpu没达到顶峰，但是某些并发大的时候变慢了，所以感觉是cop并发的影响，不过看了执行计划等待的时间又不算长，也有可能是4的执行计划没有那么细的原因，我周一再调整下并发看看

人如其名 · 2023 年5 月 14 日 00:19

是的，缺少更细的cpu时间和等待时间等。

db_user · 2023 年5 月 15 日 06:18

readpool.coprocessor.normal-concurrency从6变到7后确实有些变化，整体的延迟少了一些，但是不像这里这么明显，grafana展示有一些问题

db_user · 2023 年7 月 14 日 06:18

此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。