tikv coprocessor占用cpu很高

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

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

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

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

image


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

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

  1. TiUP Cluster Display 信息

  2. TiUP Cluster Edit Config 信息

  3. TiDB- Overview 监控

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

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

1赞

1赞

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

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

1赞

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

1赞

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

1赞

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

1赞

1赞

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

1赞
WHERE
  id = ? [arguments: NULL];

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

1赞

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

1赞

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元房费哦!戳 dpurl.cn/HHwQfGsz 回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秒
image

1赞

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

1赞

以上是tidb里的表结构

CREATE TABLE notify_result_2021 (
id int(11) NOT NULL AUTO_INCREMENT COMMENT ‘主键’,
vendor smallint(5) unsigned NOT NULL DEFAULT ‘0’ COMMENT ‘供应方’,
channel_id int(11) unsigned NOT NULL DEFAULT ‘0’ COMMENT ‘供应方渠道ID’,
notify_id int(11) NOT NULL DEFAULT ‘0’ COMMENT ‘系统唯一标志’,
send_to varchar(20) NOT NULL DEFAULT ‘’ COMMENT ‘接收人’,
encrypted_send_to varchar(100) NOT NULL DEFAULT ‘’ COMMENT ‘加密接收人’,
send_by varchar(20) NOT NULL DEFAULT ‘’ COMMENT ‘执行发送操作的人’,
content text NOT NULL COMMENT ‘发送内容’,
content_type smallint(8) DEFAULT NULL COMMENT ‘短信类型’,
template_key varchar(100) NOT NULL DEFAULT ‘’ COMMENT ‘模板key’,
extroInfo varchar(500) DEFAULT ‘’ COMMENT ‘附加信息’,
notify_type smallint(8) NOT NULL DEFAULT ‘0’ COMMENT ‘通知类型’,
request_id varchar(50) NOT NULL DEFAULT ‘’ COMMENT ‘请求ID’,
system_id int(11) NOT NULL DEFAULT ‘0’ COMMENT ‘请求系统ID’,
send_Channel_time datetime NOT NULL COMMENT ‘发送到渠道的时间’,
send_channel_result tinyint(4) NOT NULL COMMENT ‘发送结果’,
send_channel_response text DEFAULT NULL COMMENT ‘发送应答’,
message_id varchar(50) DEFAULT ‘’ COMMENT ‘消息ID’,
send_num smallint(8) unsigned NOT NULL DEFAULT ‘1’ COMMENT ‘业务发送条数’,
send_vendor_num smallint(8) unsigned NOT NULL DEFAULT ‘1’ COMMENT ‘通道商发送条数’,
origin varchar(50) NOT NULL DEFAULT ‘’ COMMENT ‘来源’,
json_info text DEFAULT NULL COMMENT ‘拓展信息’,
is_valid tinyint(4) DEFAULT ‘1’ COMMENT ‘是否生效’,
created_by int(11) unsigned NOT NULL DEFAULT ‘0’ COMMENT ‘创建者’,
created_at datetime DEFAULT NULL COMMENT ‘创建时间’,
updated_by int(11) unsigned NOT NULL DEFAULT ‘0’ COMMENT ‘修改者’,
updated_at datetime DEFAULT NULL COMMENT ‘修改时间’,
PRIMARY KEY (id),
KEY idx_messageId (message_id),
KEY idx_s_n (send_to,notify_id),
KEY idx_c_c (created_at,channel_id),
KEY idx_s_r (system_id,request_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin AUTO_INCREMENT=57059300 COMMENT=‘信息结果表’

1赞

以上是mysql的表结构

另外,两个库的sql_mode是一致的都是
STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION

1赞

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

1赞

好的,谢谢

1赞

客气了,应该的

1赞

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

1赞

好的,收到

1赞

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

1赞