问题描述
TDSQL-C MySQL 版集群 CPU 利用率过高通常容易导致系统异常,例如:响应变慢、无法获取连接、超时等,大量的超时重试往往是性能“雪崩”的罪魁祸首。CPU 利用率过高场景,很多时候都是由异常 SQL 所导致,大量锁冲突、锁等待或事务未提交也有可能导致实例 CPU 利用率高。
当数据库执行业务查询、修改语句时,CPU 会先从内存中请求数据块:
如果内存中存在对应的数据,CPU 执行计算任务后会将结果返回给用户,可能涉及到排序类高消耗 CPU 的动作。
如果内存中不存在对应的数据,数据库会触发从磁盘获取数据的动作。
这两个数据获取过程分别称为逻辑读和物理读。因此,性能较低的 SQL,在执行时容易让数据库产生大量的逻辑读,从而导致 CPU 利用率过高,也可能让数据库产生大量的物理读,从而导致 IOPS 和 I/O 时延过高。
解决方案
异常诊断:7 * 24小时异常发现诊断,提供实时优化建议。
慢 SQL 分析:针对当前实例出现的慢 SQL 进行分析,并给出慢 SQL 的优化建议。
审计日志分析:利用云数据库审计数据(全量 SQL),多维度深入分析 SQL 语句并给出优化建议。
方式一:使用“异常诊断”功能排查数据库异常情况(推荐)
异常诊断功能提供故障主动定位和优化,不需要任何数据库运维经验,不仅包括 CPU 利用率过高的异常,还几乎涵盖所有集群下读写实例或只读实例高频的异常和故障。
操作步骤及示例如下:
2. 在左上角选择实例 ID(可输入和搜索),切换至目标实例。
3. 在页面中选择实时或历史要查询的时间,若该时间段内存在故障,可在右侧的“诊断提示”中查看到概要信息。
4. 单击“实时/历史诊断”栏的查看详情或诊断提示栏的诊断项可进入诊断详情页。
事件概要:包括诊断项、起止时间、风险等级、持续时长、概要等信息。
现象描述:异常事件(或健康巡检事件)的外在表现现象的快照和性能趋势。
智能分析:分析导致性能异常的根本原因,定位具体操作。
专家建议:提供优化指导建议,包括但不限于 SQL 优化(索引建议、重写建议)、资源配置优化和参数调优。
5. 选择优化建议页,即可查看 DBbrain 针对该故障给出的优化建议,本例中是 SQL 语句的优化建议。
方式二:使用“慢 SQL 分析”功能排查导致 CPU 利用率过高的 SQL
2. 在左上角选择实例 ID(可输入和搜索),切换至目标实例。
3. 在页面中选择要查询的时间,若此实例在该时间段中有慢 SQL,SQL 统计会以柱形图的方式展示慢 SQL 产生的时间点和个数。
单击柱形图,下方的列表会显示对应的所有慢 SQL 信息(模板聚合之后的 SQL),右方会显示该时间段内 SQL 的耗时分布。
4. 针对 SQL 列表中 SQL 执行的数据进行判断和筛选,下面简单介绍一种判断方式:
4.1 先按照平均耗时(或者最大耗时)降序,重点关注耗时处在 top 的 SQL,不推荐使用总耗时,容易受到执行次数多而累加的干扰。
4.2 然后关注返回行数和扫描行数的值。
若发现“返回行数”与“扫描行数”值相等的 SQL,大概率是全表查找并返回了。
若发现几行 SQL 都有很多扫描行数,但返回行数都为0或特别小,说明系统产生了大量的逻辑读和物理读。当查找的数据量过大且内存不足时,该请求必然会产生大量的物理 I/O 请求,导致 I/O 资源大量消耗;大量的逻辑读便会占用大量的 CPU 资源,导致 CPU 利用率过高。
5. 单击 SQL 语句,可查看该 SQL 语句的详情、资源消耗以及优化建议。
分析页:可查看完整的 SQL 模板、SQL 样例以及优化建议和说明,可根据 DBbrain 给出的专家建议优化 SQL,提升 SQL 性能,降低 SQL 执行的耗时。
统计页:可根据统计报表的总耗时占比、总锁等待时间占比、总扫描行数占比、总返回行数占比,横向分析该条慢 SQL 产生的具体原因,以及进行对应优化。
明细页:可查看该类型的 SQL 的 user 来源、IP 来源、数据库以及其他明细信息。
本页内容是否解决了您的问题?