tikv节点cpu压力升高排查

为提高效率,提问时请提供以下信息,问题描述清晰可优先响应。

  • 【TiDB 版本】:v3.0.11
  • 【问题描述】:

{‘tidb_log_dir’: ‘{{ deploy_dir }}/log’, ‘dummy’: None, ‘tidb_port’: 4000, ‘tidb_status_port’: 10080, ‘tidb_cert_dir’: ‘{{ deploy_dir }}/conf/ssl’}

系统信息
+--------------+-----------------------------+
|     Host     |           Release           |
+--------------+-----------------------------+
|   tidb-mon   | 3.10.0-1062.12.1.el7.x86_64 |
|   tidb-kv1   | 3.10.0-1062.12.1.el7.x86_64 |
|   tidb-kv2   | 3.10.0-1062.12.1.el7.x86_64 |
|   tidb-kv3   | 3.10.0-1062.12.1.el7.x86_64 |
| tidb-pd1-db1 | 3.10.0-1062.12.1.el7.x86_64 |
| tidb-pd2-db2 | 3.10.0-1062.12.1.el7.x86_64 |
|   tidb-pd3   | 3.10.0-1062.12.1.el7.x86_64 |
+--------------+-----------------------------+
TiDB 集群信息
+---------------------+--------------+------+----+------+
|     TiDB_version    | Clu_replicas | TiDB | PD | TiKV |
+---------------------+--------------+------+----+------+
| 5.7.25-TiDB-v3.0.11 |      3       |  2   | 3  |  3   |
+---------------------+--------------+------+----+------+
集群节点信息
+------------+-------------+
|  Node_IP   | Server_info |
+------------+-------------+
| instance_0 |     tikv    |
| instance_1 |     tikv    |
| instance_2 |     tikv    |
| instance_3 |   pd+tidb   |
| instance_4 |   tidb+pd   |
| instance_5 |      pd     |
+------------+-------------+
容量 & region 数量
+---------------------+-----------------+--------------+
| Storage_capacity_GB | Storage_uesd_GB | Region_count |
+---------------------+-----------------+--------------+
|       4535.30       |     1445.54     |    103269    |
+---------------------+-----------------+--------------+
QPS
+---------+----------------+-----------------+
| Clu_QPS | Duration_99_MS | Duration_999_MS |
+---------+----------------+-----------------+
| 3833.89 |     63.21      |      109.66     |
+---------+----------------+-----------------+
热点 region 信息
+---------+----------+-----------+
|  Store  | Hot_read | Hot_write |
+---------+----------+-----------+
| store-1 |    6     |     4     |
| store-5 |    5     |     5     |
| store-4 |    5     |     5     |
+---------+----------+-----------+
磁盘延迟信息
+--------+------------+-------------+--------------+
| Device |  Instance  | Read_lat_MS | Write_lat_MS |
+--------+------------+-------------+--------------+
|  dm-0  | instance_0 |     nan     |     nan      |
|  dm-0  | instance_1 |     nan     |     nan      |
|  dm-0  | instance_2 |     nan     |     0.74     |
|  dm-0  | instance_3 |     nan     |     0.00     |
|  dm-0  | instance_4 |     nan     |     0.00     |
|  dm-0  | instance_5 |     nan     |     0.00     |
|  dm-1  | instance_0 |     nan     |     nan      |
|  dm-1  | instance_1 |     nan     |     nan      |
|  dm-1  | instance_2 |     nan     |     nan      |
|  dm-1  | instance_3 |     nan     |     nan      |
|  dm-1  | instance_4 |     nan     |     nan      |
|  dm-1  | instance_5 |     nan     |     nan      |
|  sda   | instance_0 |     nan     |     nan      |
|  sda   | instance_1 |     nan     |     nan      |
|  sda   | instance_2 |     nan     |     0.75     |
|  sda   | instance_3 |     nan     |     0.00     |
|  sda   | instance_4 |     nan     |     0.00     |
|  sda   | instance_5 |     nan     |     0.00     |
|  sdb   | instance_0 |     0.19    |     0.12     |
|  sdb   | instance_1 |     0.28    |     0.12     |
|  sdb   | instance_2 |     0.16    |     0.11     |
|  sdb   | instance_3 |     nan     |     0.14     |
|  sdb   | instance_4 |     nan     |     0.08     |
|  sdb   | instance_5 |     nan     |     0.14     |
|  sr0   | instance_0 |     nan     |     nan      |
|  sr0   | instance_1 |     nan     |     nan      |
|  sr0   | instance_2 |     nan     |     nan      |
|  sr0   | instance_3 |     nan     |     nan      |
|  sr0   | instance_4 |     nan     |     nan      |
|  sr0   | instance_5 |     nan     |     nan      |
+--------+------------+-------------+--------------+

从昨天下午14:12分钟左右开始,3个tikv节点cpu使用一直处于繁忙状态,如下图

pd监控图

这种现象是热点问题吗?要怎么排查?

  1. 请上传 detail-tikv 监控,可以使用以下方法截图

(1)、chrome 安装这个插件https://chrome.google.com/webstore/detail/full-page-screen-capture/fdpohaocaechififmbbbbbknoalclacl

(2)、鼠标焦点置于 Dashboard 上,按 ?可显示所有快捷键,先按 d 再按 E 可将所有 Rows 的 Panels 打开,需等待一段时间待页面加载完成。

(3)、使用这个 full-page-screen-capture 插件进行截屏保存

  1. 当前还是一直高,请在主机执行 top 命令确认是否哪个进程高,多谢。

现在有时高有时低,就是想知道排查思路是什么?

目前已定位到问题点,是一个定时任务脚本中SQL执行有异常。在20号之前一直都是1秒内执行完,从20号14点12分左右以后,这个任务需要执行80秒左右,而且中间还有很多批次是失败的

确认了一下,有异常的这个sql对应的表昨天没有删索引添加索引这些DDL操作,数据量没有异常增大

目前关闭这个定时任务,cpu使用立即恢复正常,具体sql为什么变慢还不清楚

  1. 看监控主要是 coprocessor cpu 升高对吗? 其他的截图没有反馈。

  1. sql 慢先查看统计信息是否正确,可以尝试收集统计信息。

应该是索引失效引起的。

表结构如下:
CREATE TABLE `xxx` (
  `id` bigint(11) NOT NULL AUTO_INCREMENT,
  `user_id` int(11) NOT NULL,
  ... ...
  `source_type` tinyint(3) unsigned NOT NULL DEFAULT '1',
  `pay_time` int(11) DEFAULT NULL,
  `created_at` int(11) NOT NULL,
  ... ...
  PRIMARY KEY (`id`),
  KEY `idx_xxx_userId` (`user_id`),
  KEY `idx_xxx_createdat` (`created_at`),
  KEY `idx_xxx_paytime` (`pay_time`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8

语句如下:
select count(*),
	,sum(case when o.source_type = 1 then 1 else 0 end) 'a'
	,sum(case when o.source_type = 5 then 1 else 0 end) 'b'
	,sum(case when o.source_type = 6 then 1 else 0 end) 'c'
	,sum(case when o.source_type = 7 then 1 else 0 end) 'd'
	,sum(case when o.source_type = 9 then 1 else 0 end) 'e'
from xxx o
where o.created_at > (unix_timestamp()-86400) and o.pay_time > 0
having count(*) > 200;

20号之前执行都是毫秒出数据,昨天这个SQL单独执行需要20几秒,然后使用force index(idx_xxx_createdat)强制使用created_at索引,数据毫秒就出来了。晚上再手工analyze table。

现在有个疑问,就是xxx表最近都没有修改表结构,每天数据增加也平稳,索引突然失效了,这个怎么查原因呢?

  1. 看起来都是查询sql对吧,执行下 explain analyze sql ,看看 20s 的执行计划,多谢。
  2. 感觉应该是统计信息不准确,导致执行计划没有走索引吧。

是的,脚本里面都是查询语句,问题sql语句有两个,查询的是同一张表,上面我只列出一个sql,问题是一样的 下图是截取了不加force index与加force index的explain analyze

查了下这张表的统计信息及健康度

analyze自动更新参数没有修改过,tidb_auto_analyze_ratio默认是修改50%才更新,这个默认值是不是太大了,需要设置低一点吗?

而且这张表是频繁insert +update,如果不及时更新,统计信息是不是很容易不准?

  1. 这个 tidb_auto_analyze_ratio 的默认值,可以根据您那里的实际数据变化的情况进行修改。

  2. 统计信息不准确会在一定程度上会影响优化器的选择。如果是核心表,建议单独针对该表提供一个定时任务,在业务低峰期执行,收集该表的统计信息。

  3. 在 4.0 版本,提供了 SPM 可以关注下。

好的,看来对于这些频繁更新的表,只能用crontab来定时收集了。

升级4.0已经测试过了,坐等稳定版发布后升级

:handshake::handshake::handshake: