索引查询抖动问题

【 TiDB 使用环境】生产环境
【 TiDB 版本】V7.1.1
【遇到的问题:问题现象及影响】
1.命中索引的扫描,扫描行数在14-700条之间,但执行期间偶尔会从几十ms抖动到几百ms



执行计划

id task estRows operator info actRows execution info memory disk
IndexLookUp_10 root 16.03 411 time:217.4ms, loops:2, index_task: {total_time: 126.2ms, fetch_handle: 126.2ms, build: 980ns, wait: 3.75µs}, table_task: {total_time: 91ms, num: 1, concurrency: 5}, next: {wait_index: 126.3ms, wait_table_lookup_build: 497.5µs, wait_table_lookup_resp: 90.4ms} 94.5 KB N/A
├─IndexRangeScan_8(Build) cop[tikv] 16.03 table:qa_wanliu_order_finished, index:idx_driver_id_finish_time(driver_id, finish_time), range:[71933 2023-12-05 00:00:00,71933 2023-12-15 23:00:00], keep order:false 411 time:126.2ms, loops:3, cop_task: {num: 2, max: 65.1ms, min: 60.9ms, avg: 63ms, p95: 65.1ms, max_proc_keys: 224, p95_proc_keys: 224, tot_proc: 820.9µs, tot_wait: 124.5ms, rpc_num: 2, rpc_time: 126ms, copr_cache_hit_ratio: 0.00, build_task_duration: 26.3µs, max_distsql_concurrency: 1}, tikv_task:{proc max:0s, min:0s, avg: 0s, p80:0s, p95:0s, iters:6, tasks:2}, scan_detail: {total_process_keys: 411, total_process_keys_size: 48498, total_keys: 413, get_snapshot_time: 70.2ms, rocksdb: {key_skipped_count: 411, block: {cache_hit_count: 27}}} N/A N/A
└─TableRowIDScan_9(Probe) cop[tikv] 16.03 table:qa_wanliu_order_finished, keep order:false 411 time:90.4ms, loops:2, cop_task: {num: 34, max: 85.9ms, min: 2.14ms, avg: 15.5ms, p95: 56ms, max_proc_keys: 19, p95_proc_keys: 18, tot_proc: 22.5ms, tot_wait: 456.7ms, rpc_num: 34, rpc_time: 524.9ms, copr_cache_hit_ratio: 0.00, build_task_duration: 142.6µs, max_distsql_concurrency: 1, max_extra_concurrency: 14}, tikv_task:{proc max:31ms, min:0s, avg: 1.65ms, p80:1ms, p95:3ms, iters:34, tasks:34}, scan_detail: {total_process_keys: 411, total_process_keys_size: 120631, total_keys: 425, get_snapshot_time: 274ms, rocksdb: {key_skipped_count: 42, block: {cache_hit_count: 4352}}} N/A N/A

当时总体QPS

TIKV监控

【资源配置】
7T nvme,48超线程,125G内存

看上去很像统计信息过期

但我刚才查看基本信息,发现统计信息是准确的


有没有可能抖动的时候,正好是tikv节点在调度region。可以配合监控看一下

到达一定量级后,会出现大面积几百ms延迟。昨天此SQL在1500QPS时,延迟就涨了很多倍。

你都是等待耗时 你连监控都不会看

数据库又不是你一家的 还有其他sql在跑的

确实不太会,一直都是自己摸索。需要看哪些监控呢

这个是昨天压测的结果,SQL是我们和业务控制的,只是单独给这一个SQL涨流量,其它SQL流量没变。然后出现大面积延迟

这个sql延迟升高只是结果,qps增加整个服务器的延迟就会上升。可以看下sql语句分析中哪些sql消耗资源最多

延迟变化情况

语句分析

TiKV读线程池监控看下

是这些吗

读线程池压力有点高

网络有没有问题

image
这个图这里写得很清楚了,这个SQL语句的执行就是 Coprocessor 过程耗时最久。

Coprocessor 表示的是一个SQL执行过程到tikv存储层读取数据的操作,这个操作时间最久,说明在tikv读取数据时间过长是最关键的瓶颈点。

重点关注一下这个Coprocessor 读取数据时集中在哪几个tikv节点,这个在 Dashboard上可以查看。
然后到tikv -details grafana 监控面板,查看一下对应tikv的IO、Region 调度登录情况,看看有没有明显的异常。

你的这个图,Unified Read Pool CPU 很高,高出了预警线,也说明了是在tikv读取数据压力比较大。

请确认在这个时段,是不是有其他大 SQL 在同时执行读取大量数据,导致集群变慢了。

1 个赞

可以查看这两篇文章的思路,具体都排查一下读压力比较大的tikv节点,看看是不是有 读热点问题。

抖动发生时数据库有没有其它慢SQL出现,除非你在单独环境测试,没有其它干扰