实例监控
本文介绍 DRDS 的性能监控功能,如何分析性能指标并根据指标排查 DRDS 性能问题。
查看监控信息
在 DRDS 控制台的实例列表页,单击需要操作的实例名称。
在实例基本信息页,在左侧菜单栏监控与报警中选择实例监控,进入监控详情页。
实例监控主要分为资源监控和 DRDS 引擎监控。引擎层面的监控指标又可以分成 DRDS 实例级别和 DRDS 库级别两个维度的监控,当某些引擎类的监控指标出现异常的时候,可以直接查看各个数据库的监控指标,从而定位到有性能问题的数据库。下文针对这两类监控下的各指标进行详细说明。
监控指标技术说明
监控项 | 监控项分类 | 含义 | 数据采集周期 | 数据保留时长 | 说明 |
---|---|---|---|---|---|
CPU 利用率 | 资源监控 | DRDS 服务节点的 CPU 利用率的平均值 | 1分钟 | 3天 | |
内存利用率 | 资源监控 | DRDS 服务节点的 JVM Old Generation 的内存使用率 | 1分钟 | 3天 | 内存使用率波动属于正常现象 |
网络输入流量 | 资源监控 | DRDS 服务节点的网络输入流量的总和 | 1分钟 | 3天 | RDS 返回数据到 DRDS,会产生网络输入流量 |
网络输出流量 | 资源监控 | DRDS 服务节点的网络输出流量的总和 | 1分钟 | 3天 | DRDS 发送物理 SQL 到 RDS,DRDS 返回数据到应用,均会产生网络输出流量 |
逻辑 QPS | 引擎监控 | DRDS 服务节点每秒处理的 SQL 语句数目的总和 | 5秒 | 7天 | |
物理 QPS | 引擎监控 | DRDS 服务节点每秒发送到 RDS 的 SQL 操作数总和 | 5秒 | 7天 | 一条逻辑 SQL 可能会拆分成多条物理 SQL |
逻辑 RT | 引擎监控 | DRDS 对于每条 SQL 的平均响应时间 | 5秒 | 7天 | 如果逻辑 SQL 会变成物理 SQL 下发,那么此条 SQL 的 逻辑 RT 会包含物理 SQL 的 RT |
物理 RT | 引擎监控 | DRDS 发送到 RDS 的 SQL 的平均响应时间 | 5秒 | 7天 | |
连接数 | 引擎监控 | 应用到 DRDS 的连接总数 | 5秒 | 7天 | 不包括 DRDS 到 RDS 的连接 |
活跃线程数 | 引擎监控 | DRDS 用来执行 SQL 的线程数 | 5秒 | 7天 |
监控指标原理
在分析监控指标之前,需要对 SQL 语句在 DRDS 上的执行流程进行了解。
在整个 SQL 的执行链路中,第2到第4步的执行状况都会在 DRDS 的各个监控指标上有所体现。
第2步:SQL 解析、优化、执行,主要消耗的是 CPU 资源。越是复杂的 SQL(结构复杂或者超长),消耗的 CPU 资源就越大。通过 TRACE 指令跟踪 SQL 的执行过程,可以看到一条 SQL 在优化 阶段的耗时。这部分的耗时越高,表示 CPU 资源消耗的就越高。
第3步:物理 SQL 下发和执行,主要消耗的是 IO 资源,可以通过逻辑、物理的 QPS 和 RT 等指标分析出这一部分的执行状况。例如,如果物理 QPS 很低同时 物理 RT 很高,表示当前 RDS 处理 SQL 很慢,需要关注 RDS 的性能。
第5步:SQL 执行结果处理、整合,这部分操作主要是用来对物理 SQL 的执行结果进行转换。多数情况下,此类转换只会进行一些 SQL 元信息的转换,资源消耗很小。但是当出现
heap sort
等执行步骤的时候,则会消耗非常高的 CPU 资源。关于如何确定 SQL 在此阶段的消耗,可以参考排查 DRDS 慢 SQL文档中关于TRACE
指令的说明。
预防性能问题
对于常见的数据库性能问题,结合性能监控指标,可以得到比较有效的处理方法。
示例一:性能监控指标随着业务流量的变化而变化
性能指标往往会随着当前系统业务量的波动而波动。以下是常见的两种情况:
某应用在每天早上9点会有抢购活动,所以这个时间点整个系统的业务流量会有一个明显的增长。从监控数据上来看,DRDS 的 CPU 利用率从9点开始从20%增长到80%左右,整个高峰持续10分钟左右。
某应用业务一直在增长,系统的业务流量也随着一直增长,直到稳定到一个水平线。DRDS 的 CPU 监控数据也基本上反应了这一变化。
在 DRDS 的压力随着业务变化而变化的时候,应该密切关注监控指标的变化。如果超过预设的阈值,则应该通过进行 DRDS 升配缓解性能压力。
在 DRDS 控制台可以针对实例设置报警规则,当 CPU 的平均值超过预设的阈值的时候,系统会方发送短信到对应的联系人。CPU 的阈值可以根据实际情况设定,推荐设置成80%。
示例二:观察逻辑 RT 和物理 RT 的差值
逻辑 RT 指的是 DRDS 从收到逻辑 SQL 到返回数据给应用的响应时间,物理 RT 指的是 DRDS 从发出物理 SQL 到 RDS 至收到 RDS 返回数据的时间。
如果一条逻辑 SQL 被拆分成了一条或者多条物理 SQL 那么逻辑 RT 会大于等于物理 RT。理想情况下,DRDS 只会对于 RDS 返回过来的数据进行少量的操作,所以一般情况下逻辑 RT 只会略高于物理 RT 一点。但是某些情况下,物理的 SQL 执行很快,而逻辑 SQL 处理时间很久,则逻辑 RT 和物理 RT 会分别出现如下的走向:
从上面两个监控图可以看到,逻辑 RT 和物理 RT 的变化趋势大致一样,逻辑 RT 在10毫秒到20毫秒范围内波动,物理 RT 在2毫秒到5毫秒范围内波动。这说明 DRDS 层面已经有较大的压力。这种情况可以通过升级 DRDS 配置来解决性能问题。相反,如果逻辑 RT 和 物理 RT 都很高,那么可以通过升级 RDS 的配置或者在 RDS 层面优化 SQL 来解决性能问题。
示例三:观察逻辑 QPS 和物理 QPS 的差值
从监控数据上来看,逻辑 QPS 和物理 QPS 的趋势相同,但是两者有差值比较大,且成一定的比例。
根据监控指标显示,逻辑 QPS 在80至150这个范围内波动,物理 QPS 在700至1200这个范围内波动。
造成这种现象的原因是 DRDS 会根据逻辑 SQL 生成物理 SQL,逻辑 SQL 和物理 SQL 的数量比例并不是1:1的关系。例如有一个 DRDS 逻辑表,建表语句如下:
CREATE TABLE drds_user
(id int,
name varchar(30))
dbpartition by hash(id);
当查询条件带上分库键id
,DRDS 会将这条逻辑 SQL 直接下推到 RDS 去执行,从执行计划上可知,物理 SQL 的数目是1条:
mysql> explain select name from drds_user where id = 1;
+---------------------------+-------------------------------------------------------------------------+--------+
| GROUP_NAME | SQL | PARAMS |
+---------------------------+-------------------------------------------------------------------------+--------+
| SANGUAN_BSQT_0001_RDS | select `drds_user`.`name` from `drds_user` where (`drds_user`.`id` = 1) | {} |
+---------------------------+-------------------------------------------------------------------------+--------+
当查询没有带上分库键,DRDS 会将逻辑 SQL 拆分成多条条物理 SQL。从下面的执行计划可知,物理 SQL 的数目是8条。
mysql> explain select name from drds_user where name = 'LiLei';
+----------- ---------------+---------------------------------------------------------------------------------+--------+
| GROUP_NAME | SQL | PARAMS |
+---------------------------+---------------------------------------------------------------------------------+--------+
| SANGUAN_BSQT_0001_RDS | select `drds_user`.`name` from `drds_user` where (`drds_user`.`name` = 'LiLei') | {} |
| SANGUAN_BSQT_0001_RDS | select `drds_user`.`name` from `drds_user` where (`drds_user`.`name` = 'LiLei') | {} |
| SANGUAN_BSQT_0001_RDS | select `drds_user`.`name` from `drds_user` where (`drds_user`.`name` = 'LiLei') | {} |
| SANGUAN_BSQT_0001_RDS | select `drds_user`.`name` from `drds_user` where (`drds_user`.`name` = 'LiLei') | {} |
| SANGUAN_BSQT_0001_RDS | select `drds_user`.`name` from `drds_user` where (`drds_user`.`name` = 'LiLei') | {} |
| SANGUAN_BSQT_0001_RDS | select `drds_user`.`name` from `drds_user` where (`drds_user`.`name` = 'LiLei') | {} |
| SANGUAN_BSQT_0001_RDS | select `drds_user`.`name` from `drds_user` where (`drds_user`.`name` = 'LiLei') | {} |
| SANGUAN_BSQT_0001_RDS | select `drds_user`.`name` from `drds_user` where (`drds_user`.`name` = 'LiLei') | {} |
+---------------------------+---------------------------------------------------------------------------------+--------+
8 rows in set (0.06 sec)
逻辑/物理 QPS 指的是在单位时间内处理的逻辑/物理 SQL 语句的总数。当整个系统的多数 SQL 都带上了拆分条件,逻辑 QPS 和 物理 QPS 的比值应该是接近于 1:1。逻辑 QPS 和 物理 QPS 的差值过于大则意味着当前应用有很多 SQL 语句没有带拆分条件,应该排查应用的 SQL 语句,提高性能。
示例四:内存使用率过高
DRDS内存使用率过高,大部分情况下是由于用户应用的SQL有大批量查询,返回结果集过大导致。如果您的DRDS实例内存使用率持续接近100%,此时您需要执行【重启实例】的操作,定位并优化应用的低效SQL。
版权声明
本文仅代表作者观点,不代表本站立场。
本文系作者授权发表,未经许可,不得转载。
评论