tikv coprocessor占用cpu很高

为提高效率,请提供以下信息,问题描述清晰能够更快得到解决:
【 TiDB 使用环境】centos 7.5

【概述】tikv coprocessor 占用cpu很高,业务上的sql并不多,都是查询sql,where条件都有主键id过滤,而且只查一条数据,但是却要执行10多秒

【背景】没做任何操作,tikv的cpu突然就升高了

【现象】业务和数据库现象
tikv cpu使用率飙升,出现了很多慢查询


【业务影响】
业务变慢很多

【TiDB 版本】
v4.0.13
【附件】

  1. TiUP Cluster Display 信息

  2. TiUP Cluster Edit Config 信息

  3. TiDB- Overview 监控

  • 对应模块日志(包含问题前后1小时日志)

若提问为性能优化、故障排查类问题,请下载脚本运行。终端输出的打印结果,请务必全选并复制粘贴上传。

3 个赞

4 个赞

这个如果是突然升高的,建议看看当前 正在执行的 SQL,先优化 SQL(查询 information_schema.cluster_process 表)
或者分析慢日志(最近一段时间的,根据内存/process_key 排序)

2、优化SQL 方法,可以用 hint 或者 SPM 功能
3、紧急处理,可以关注一下 oom-action 等相关参数

3 个赞

另外,你的集群存在热点现象

3 个赞

慢查询的sql都很简单,都是按照主键查的一条数据

3 个赞

请教下,SELECT * FROM table1 WHERE id = NULL;
这个sql里,表 table1 的字段id是主键,表有3000万条数据,
我手动执行sql,瞬间出来了,
但是应用断发起的批量sql里,有很多变成了慢查询,执行计划变成可全表扫描,
像这种 id = NULL 应该也走索引才对吧?

3 个赞

3 个赞

没有走索引:joy:(主键为什么会有 null)

3 个赞
WHERE
  id = ? [arguments: NULL];

语法是类似这样的,当arguments有值的时候,取arguments,当arguments无值的时候,为NULL;
刚用同样的sql试了,mysql是走了索引,结果秒出,tidb没走索引

3 个赞

mysql 走索引了?能发一下 mysql 的执行计划吗(及 mysql 版本),另外,我需要确认 mysql 及 tidb 的表结构是否一致(表结构最好发一下)

3 个赞

MySQL [br_sms]> set @s = ‘SELECT id, vendor, channel_id, notify_id, send_to, encrypted_send_to, send_by, content_type, template_key, extroInfo, notify_type, request_id, system_id, send_Channel_time, send_channel_result, message_id, send_num, send_vendor_num, origin, is_valid, created_by, created_at, updated_by, updated_at, content, send_channel_response, json_info FROM notify_result_2021 WHERE id = ?’;
Query OK, 0 rows affected (0.00 sec)

MySQL [br_sms]>
MySQL [br_sms]> prepare stmt2 from @s;
Query OK, 0 rows affected (0.00 sec)

MySQL [br_sms]> set @c=null;
Query OK, 0 rows affected (0.00 sec)

MySQL [br_sms]> execute stmt2 using @c;
Empty set (16.62 sec)

MySQL [br_sms]>
MySQL [br_sms]>
MySQL [br_sms]> set @c=31194373;
Query OK, 0 rows affected (0.00 sec)

MySQL [br_sms]> execute stmt2 using @c;
±---------±-------±-----------±----------±------------±------------------±--------±-------------±-------------------±-------------±------------±---------------------------------±----------±--------------------±--------------------±-------------------±---------±----------------±-------±---------±-----------±--------------------±-----------±--------------------±-----------------------------------------------------------------------------------------------------------------±----------------------------------------------------------------------------------------------------------------------------------------------------------±----------+
| id | vendor | channel_id | notify_id | send_to | encrypted_send_to | send_by | content_type | template_key | extroInfo | notify_type | request_id | system_id | send_Channel_time | send_channel_result | message_id | send_num | send_vendor_num | origin | is_valid | created_by | created_at | updated_by | updated_at | content | send_channel_response | json_info |
±---------±-------±-----------±----------±------------±------------------±--------±-------------±-------------------±-------------±------------±---------------------------------±----------±--------------------±--------------------±-------------------±---------±----------------±-------±---------±-----------±--------------------±-----------±--------------------±-----------------------------------------------------------------------------------------------------------------±----------------------------------------------------------------------------------------------------------------------------------------------------------±----------+
| 31194373 | 29 | 2401 | 15424234 | 14411161122 | | | 2401 | 元知测试模板 | 未知错误 | 1 | 3a20d9e8606b41c3a26ab1b432473f76 | 1125 | 2021-06-01 22:04:49 | 1 | 210601220448782820 | 1 | 1 | | 1 | 0 | 2021-06-01 22:04:49 | 0 | 2021-06-01 22:04:49 | 【美团民宿】分享入住美团民宿的体验,可返2.04元房费哦!戳 打开美团 回TD退订 | {“code”:“F0100”,“desc”:“未知错误”,“uid”:“3f1857d618434d3b8b905f4a87475c01”,“result”:[{“status”:“F0100”,“phone”:“14411161122”,“desc”:“未知错误”}]} | NULL |
±---------±-------±-----------±----------±------------±------------------±--------±-------------±-------------------±-------------±------------±---------------------------------±----------±--------------------±--------------------±-------------------±---------±----------------±-------±---------±-----------±--------------------±-----------±--------------------±-----------------------------------------------------------------------------------------------------------------±----------------------------------------------------------------------------------------------------------------------------------------------------------±----------+
1 row in set (0.01 sec)

MySQL [br_sms]>

以上是tidb里执行的情况,null的时候执行16秒

2 个赞

以上是mysql执行的截图,执行时间是0.04秒

2 个赞

收到,这个确实可以优化,我反馈一下(不过基于先解决问题,建议咱们程序还是 看看能不能避免 null 的情况)

2 个赞

好的,谢谢

2 个赞

客气了,应该的

2 个赞

https://github.com/pingcap/tidb/issues/26431 可以关注一下 这个 issue 哈

2 个赞

好的,收到

2 个赞

:ok_hand:现在解决的方式,可以使用一下 hint/spm 等方式(可以尝试一下哈,一会我也测试一下,我没试过这个场景),ps: 不过程序上避免这个情况,更好

1 个赞

hint 好像不起作用

1 个赞

@magongyong 麻烦帮在 tidb 库里,执行一下 explain analyze sql语句的结果吧(想确认一个信息)

1 个赞