tidb-v6 慢查询原因分析

【 TiDB 使用环境】生产环境
【 TiDB 版本】tidb-v6.1.3
【复现路径】从5.4.2 升级到6.1.3
【遇到的问题:问题现象及影响】
业务一个请求SQL 请求量波动,导致tikv cpu 突增。 手动查看sql 执行计划用到正确的索引,且执行速度0.05s
但是在慢查询中看到大量慢查询在0.5s 以上,且wait_time 字段较大。如何分析具体的性能瓶颈 ?

【附件:截图/日志/监控】
1、OverView 监控



2、之前是gc 保留时间比较长48h, 改成20min 后依然出现抖动的现象

3、慢查询信息

MySQL [INFORMATION_SCHEMA]> select * from CLUSTER_SLOW_QUERY where time >'2023-01-16 14:50:01'  and  query like 'SELECT * FROM `tbl_device_phone_log`%' limit 1\G
*************************** 1. row ***************************
                     INSTANCE: 10.105.128.254:10094
                         Time: 2023-01-16 14:50:01.004791
                 Txn_start_ts: 438790206288560132
                         User: kunpengdm_app
                         Host: 10.108.83.77
                      Conn_ID: 7677287164388118587
             Exec_retry_count: 0
              Exec_retry_time: 0
                   Query_time: 0.883878422
                   Parse_time: 0
                 Compile_time: 0.000522455
                 Rewrite_time: 0.000089441
           Preproc_subqueries: 0
      Preproc_subqueries_time: 0
                Optimize_time: 0.000326578
                      Wait_TS: 0.000014092
                Prewrite_time: 0
    Wait_prewrite_binlog_time: 0
                  Commit_time: 0
           Get_commit_ts_time: 0
          Commit_backoff_time: 0
                Backoff_types: 
            Resolve_lock_time: 0
        Local_latch_wait_time: 0
                   Write_keys: 0
                   Write_size: 0
              Prewrite_region: 0
                    Txn_retry: 0
                     Cop_time: 1.6118884690000002
                 Process_time: 0.407
                    Wait_time: 10.181
                 Backoff_time: 0
                LockKeys_time: 0
                Request_count: 310
                   Total_keys: 12843
                 Process_keys: 12292
 Rocksdb_delete_skipped_count: 0
    Rocksdb_key_skipped_count: 1714
Rocksdb_block_cache_hit_count: 99926
     Rocksdb_block_read_count: 0
      Rocksdb_block_read_byte: 0
                           DB: kunpeng_dms_call
                  Index_names: [tbl_device_phone_log:idx_deviceid_code]
                  Is_internal: 0
                       Digest: 3c45957328e5e5c016cb360b20cbab5d94376adcd0bac898eff708c220567f2a
                        Stats: tbl_device_phone_log:438789586999574542
                 Cop_proc_avg: 0.001312903
                 Cop_proc_p90: 0.002
                 Cop_proc_max: 0.004
                Cop_proc_addr: 10.105.128.115:20175
                 Cop_wait_avg: 0.032841935
                 Cop_wait_p90: 0.116
                 Cop_wait_max: 0.622
                Cop_wait_addr: 10.105.128.115:20175
                      Mem_max: 194849
                     Disk_max: 0
                     KV_total: 10.704811784
                     PD_total: 0.000005371
                Backoff_total: 0
     Write_sql_response_total: 0.000003124
                  Result_rows: 1
               Backoff_Detail: 
                     Prepared: 1
                         Succ: 1
                IsExplicitTxn: 0
            IsWriteCacheTable: 0
              Plan_from_cache: 0
            Plan_from_binding: 0
             Has_more_results: 0

Plan 截图

tikv-details 监控: coprocessor 部分异常
tidb-kunpeng_dms-TiKV-Details_2023-01-16T08_03_13.545Z.json (30.5 MB)

dashboard 截图




如何解读这种现象,以及如何处理?

这个表的健康度可以查下看看,这里执行计划的值看起来有点不对


这个时间点在跑什么? 要读这么多数据么…

手动查看的执行计划和表结构如下:

表的健康度如下:

手动执行

那个时间点我在慢日志里看到的是几分钟内2000多次的请求,对应的dashboard 上topsql 就是下图


我的判断就是tbl_device_phone_log 相关的 sql 请求量大导致的coprocessor 比较忙,具体的原理分析不出来

不知道是不是跟我之前设置的两天的GC 导致扫描的历史版本过多导致的。运行一晚上,明天我再看看监控。

这个表基本上不会从缓存中获取数据,无命中率…


然后 单一数据的版本特别多,需要读很多次才能拿到结果…

参考累积的 cop 的请求数量~

建议继续观察…

好的,多谢多谢。明天我再看看。我看最近三个小时已经没有大的抖动了

[请问下 最大可见数和最大遇到的版本数分别代表什么意思?

监控上看昨晚7点之后就很少波动了,到了23:00 左右有一波突增的请求,抖动就又起来了

今天上午看着还是有抖动的现象。

今天上午的一个慢查询情况

这次看着是读取到缓存了,但是还是慢

另外也问下胡杨同学的那个问题:
最大可见数和最大遇到的版本数分别代表什么意思?

我现在的gc_life_time 设置了20m,为啥还是这么多版本?

可见版本和不可见版本,在于是否有效
可见版本,就是有效的数据,不可见的,就是无效的数据(待清理的)

合并起来就是所有的版本信息

然后实际读取的时候,会优先从缓存中取,这个是最快的
缓存中取不到,就需要对磁盘进行扫描了,实际上按照 Key + version = MVCC 的处理机制,会有排序的

所以也不会一次性读取所有的,会有范围划分
但是读的数据,不一定是读的最新的,就会选择有效的版本,就会从一个范围去找有效的版本数据,这样子就演变成了遇到的版本数(因为待清理的版本,也会在里头)

反过来看,我建议你查下热点问题,是不是数据打得不够分散,导致的单个节点实例需要承载更多的请求处理过程…


GC 时间调整的生效,和数据版本的清理不是一个同步的工作

如果着急的话,想清理版本,可以通过tikv-cli 的命令来手工清理,建议寻找业务不繁忙的间隙来执行,避免造成抖动

1 个赞

对于热点问题,我上面发的监控图可以看到,抖动的时候是所有的tikv cpu 都飙升的。


年前不操作了,年后回来再看。多谢!

是不是数据分布不是很好,查询符合某个条件的时候数据量比较多,可能消耗比较大,符合条件的数据量少的时候,消耗较小

SQL查询索引不合理引起的,添加好合理索引就稳定了。作者监控图
image

1 个赞

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