update 操作执行过慢导致tikv cpu使用率超高

TiDBer_E3pRgGAy · 2023 年10 月 9 日 11:40

【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】6.5.5
【复现路径】做过哪些操作出现的问题
执行大量的update操作时，dashboard中的执行过程结果和SQL编辑器中的不一样，导致整个tikv cpu使用率都非常高而卡顿
【遇到的问题：问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】

扬仔_tidb · 2023 年10 月 9 日 11:58

执行计划好像不正确，看完整信息里可有stats:pseudo字样
https://docs.pingcap.com/zh/tidb/stable/explain-walkthrough

TiDBer_E3pRgGAy · 2023 年10 月 9 日 12:00

没有看到这个关键字

TiDB_C罗 · 2023 年10 月 9 日 12:04

看看TiDB dashboard慢查询的执行时间，具体消耗是什么

TiDBer_E3pRgGAy · 2023 年10 月 9 日 12:06

Fly-bird · 2023 年10 月 10 日 00:07

SQL语句有问题吗，建议排查下系统资源

tidb菜鸟一只 · 2023 年10 月 10 日 00:52

看着像tikv太忙了，看下tikv的资源情况吧

像风一样的男子 · 2023 年10 月 10 日 01:34

把update改成select 试试快不快

大飞哥Boil · 2023 年10 月 10 日 01:41

看下监控，tikv的资源情况，还有coprocessor cpu 监控

h5n1 · 2023 年10 月 10 日 02:30

走taskid索引不是最优的，execution_id 或者2个组合选择性才是最好的吧

有猫万事足 · 2023 年10 月 10 日 02:48

coprocessor 资源不够了。这和cpu跑满了的现象也能对上，该加cpu资源了。

不加资源的情况下，也只能看看是不是所有的tikv cpu负载都是均衡的？
另外index也确实有点问题，根据taskid找到1370行，结果根据其他条件一过滤发现没有需要修改的行，或者只有1-2行实际需要修改的。

可以看到prewrite和commit都很快，合计30ms出头一点。写入io这块应该是没什么压力，全在cpu上。

路在何chu · 2023 年10 月 10 日 02:55

机器啥配置，io情况是啥，看看tikv detail的thread cpu够用不

路在何chu · 2023 年10 月 10 日 02:56

load average: top看看这个，是够够用

TiDBer_E3pRgGAy · 2023 年10 月 10 日 06:15

kv机器是三台独立的16核64G云服务器；每次业务上大批量执行这个update语句时，几乎三台kv的cpu都飙升到80%以上，现在设置了task_id + execution_uid 的联合索引解决了这个问题；
但是有个很奇怪的问题，数据库配置是一模一样，代码也是一模一样，在6.6.0版本没有出现这些问题，而且6.6.0版本的并发比现在这边业务的并发还要高很多，因为数据库里面有很多字段存的是大json，所以我也不敢贸然升级版本到6.6.0；

像风一样的男子 · 2023 年10 月 10 日 06:16

6.6不是正式版本，不建议在生产环境使用

TiDBer_E3pRgGAy · 2023 年10 月 10 日 06:16

cpu确实不太搞用

TiDBer_E3pRgGAy · 2023 年10 月 10 日 06:18

但是现在这个6.5.5版本出现了很多SQL问题，都是执行太慢导致cpu飙升，但是这些问题之前6.6.0都没有出现过

像风一样的男子 · 2023 年10 月 10 日 06:21

sql有问题解决sql问题，6.5这个版本还是很稳定的

TiDBer_E3pRgGAy · 2023 年10 月 10 日 06:27

单表数据在1300W左右，video_mention_task 列有索引，这个更新也是同时大批量的，在这个版本就会执行很忙，而且看执行计划扫描的行数也好像不太对;

像风一样的男子 · 2023 年10 月 10 日 06:46

定期给这个表做个analyze,同一个sql2个库执行计划有偏差