tikv节点cpu压力升高排查

[hanson]

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

• 【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监控图

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

[yilong (yi888long)]

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 插件进行截屏保存

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

[hanson]

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

[hanson]

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

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

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

[yilong (yi888long)]

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

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

https://pingcap.com/docs-cn/v3.0/statistics/#统计信息简介

[hanson]

应该是索引失效引起的。

表结构如下：
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表最近都没有修改表结构，每天数据增加也平稳，索引突然失效了，这个怎么查原因呢？

[yilong (yi888long)]

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

[hanson]

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

[hanson]

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

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

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

[zhenjiaogao]

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

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

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

https://pingcap.com/docs-cn/stable/execution-plan-binding/

[hanson]

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

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

[zhenjiaogao]