全部产品
分布式关系型数据库 DRDS

DRDS 监控

更新时间:2017-06-07 13:26:11   分享:   

本文介绍 DRDS 的性能监控功能,如何分析性能指标并根据指标排查 DRDS 性能问题。

监控指标技术说明

DRDS 在控制台上提供了丰富的监控项,从指标类型上主要分为资源监控和 DRDS 引擎监控两类指标。引擎层面的监控指标又可以分成 DRDS 实例级别和 DRDS 库级别两个维度的监控,当某些引擎类的监控指标出现异常的时候,可以直接查看各个数据库的监控指标,从而定位到有性能问题的数据库。

目前 DRDS 提供的监控指标如下表:

监控项 监控项分类 含义 数据采集周期 数据保留时长 说明
CPU 利用率 资源监控 DRDS 服务节点的 CPU 利用率的平均值 5分钟 3天
网络输入流量 资源监控 DRDS 服务节点的网络输入流量的总和 5分钟 3天 RDS 返回数据到 DRDS,会产生网络输入流量
网络输出流量 资源监控 DRDS 服务节点的网络输出流量的总和 5分钟 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 上的执行流程进行了解。

DRDS SQL执行流程

在整个 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分钟左右。

    一个小时的CPU

  • 某应用业务一直在增长,系统的业务流量也随着一直增长,直到稳定到一个水平线。DRDS 的 CPU 监控数据也基本上反应了这一变化。

    一周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 和物理 RT 的变化趋势大致一样,逻辑 RT 在10毫秒到20毫秒范围内波动,物理 RT 在2毫秒到5毫秒范围内波动。这说明 DRDS 层面已经有较大的压力。这种情况可以通过升级 DRDS 配置来解决性能问题。相反,如果逻辑 RT 和 物理 RT 都很高,那么可以通过升级 RDS 的配置或者在 RDS 层面优化 SQL 来解决性能问题。

示例三:观察逻辑 QPS 和物理 QPS 的差值

从监控数据上来看,逻辑 QPS 和物理 QPS 的趋势相同,但是两者有差值比较大,且成一定的比例。

一小时逻辑 QPS

物理QPS

根据监控指标显示,逻辑 QPS 在80至150这个范围内波动,物理 QPS 在700至1200这个范围内波动。

造成这种现象的原因是DRDS 会根据逻辑 SQL 生成物理 SQL,逻辑 SQL 和物理 SQL 的数量比例并不是1:1的关系。例如有一个 DRDS 逻辑表,建表语句如下:

  1. CREATE TABLE drds_user
  2. (id int,
  3. name varchar(30))
  4. dbpartition by hash(id);

当查询条件带上分库键id,DRDS 会将这条逻辑 SQL 直接下推到 RDS 去执行,从执行计划上可知,物理 SQL 的数目是1条:

  1. mysql> explain select name from drds_user where id = 1;
  2. +---------------------------+-------------------------------------------------------------------------+--------+
  3. | GROUP_NAME | SQL | PARAMS |
  4. +---------------------------+-------------------------------------------------------------------------+--------+
  5. | SANGUAN_BSQT_0001_RDS | select `drds_user`.`name` from `drds_user` where (`drds_user`.`id` = 1) | {} |
  6. +---------------------------+-------------------------------------------------------------------------+--------+

当查询没有带上分库键,DRDS 会将逻辑 SQL 拆分成多条条物理 SQL。从下面的执行计划可知,物理 SQL 的数目是8条。

  1. mysql> explain select name from drds_user where name = 'LiLei';
  2. +----------- ---------------+---------------------------------------------------------------------------------+--------+
  3. | GROUP_NAME | SQL | PARAMS |
  4. +---------------------------+---------------------------------------------------------------------------------+--------+
  5. | SANGUAN_BSQT_0001_RDS | select `drds_user`.`name` from `drds_user` where (`drds_user`.`name` = 'LiLei') | {} |
  6. | SANGUAN_BSQT_0001_RDS | select `drds_user`.`name` from `drds_user` where (`drds_user`.`name` = 'LiLei') | {} |
  7. | SANGUAN_BSQT_0001_RDS | select `drds_user`.`name` from `drds_user` where (`drds_user`.`name` = 'LiLei') | {} |
  8. | SANGUAN_BSQT_0001_RDS | select `drds_user`.`name` from `drds_user` where (`drds_user`.`name` = 'LiLei') | {} |
  9. | SANGUAN_BSQT_0001_RDS | select `drds_user`.`name` from `drds_user` where (`drds_user`.`name` = 'LiLei') | {} |
  10. | SANGUAN_BSQT_0001_RDS | select `drds_user`.`name` from `drds_user` where (`drds_user`.`name` = 'LiLei') | {} |
  11. | SANGUAN_BSQT_0001_RDS | select `drds_user`.`name` from `drds_user` where (`drds_user`.`name` = 'LiLei') | {} |
  12. | SANGUAN_BSQT_0001_RDS | select `drds_user`.`name` from `drds_user` where (`drds_user`.`name` = 'LiLei') | {} |
  13. +---------------------------+---------------------------------------------------------------------------------+--------+
  14. 8 rows in set (0.06 sec)

逻辑/物理 QPS 指的是在单位时间内处理的逻辑/物理 SQL 语句的总数。当整个系统的多数 SQL 都带上了拆分条件,逻辑 QPS 和 物理 QPS 的比值应该是接近于 1:1。逻辑 QPS 和 物理 QPS 的差值过于大则意味着当前应用有很多 SQL 语句没有带拆分条件,应该排查应用的 SQL 语句,提高性能。

本文导读目录
本文导读目录
以上内容是否对您有帮助?