往期分享
RDS MySQL 小版本升级最佳实践
RDS MySQL 实例空间问题
RDS MySQL 内存使用问题
RDS MySQL 活跃线程数高问题
RDS MySQL 慢SQL问题
RDS MySQL 实例IO高问题
概述
CPU使用率过高问题是RDS PG用户遇到的性能问题中较常见的一类。当RDS SQL Server实例的CPU使用率持续较高时，很容易导致数据库访问卡慢的情况，例如一些很简单的查询请求的响应时间也会很久甚至超时失败。
资源监控
在RDS控制台的“监控与报警”页中的“标准监控”->“资源监控”下，可以查看指定时间段内实例的CPU使用率信息。
对于RDS PG来说，CPU使用率持续大于80%以上，通常表明系统处于高负载的情况，并且很可能存在较严重的性能问题。
CPU基本概念
- CPU使用率，CPU使用率指的是CPU执行工作时间的比例，包含了所有符合条件的活动的时钟周期，比如停滞等待IO而导致较高的使用率，CPU使用率又被分为内核时间和用户时间。
- 用户时间，执行用户态程序的时间被称为用户时间。
- 内核时间，执行内核态代码的时间为内核时间，包含系统调用，内核线程和中断的时间。
- 上下文切换，内核程序切换CPU让其在不同的地址空间上操作
- 中断，由物理设备发送给内核的信号，通常是请求I/O服务
CPU高的常见原因
扫描行高
查看资源监控可以看出CPU使用率很高。
查看引擎监控操作行数
发现存在大量的全表扫描行，这个是导致CPU高的主要问题，对于一个查询来说，如果该查询返回10行数据，我们需要尽量保证SQL通过索引扫描10行数据返回，此时效率是最高的，而不是全表扫描100W行数据后过滤掉99%的数据，返回10行给客户端。评价一个查询是否扫描行很高就可以通过该查询的返回行和扫描行相比可以知道，如果扫描行远大于返回行说明该SQL可以通过创建合适索引可以极大程度的降低SQL的响应时间以及降低CPU资源的使用率。
通过das的性能洞察可以找出问题SQL
找到慢SQL后，可以参考RDS PG慢SQL问题，进行SQL的优化。
活跃会话高
查看资源监控
发现CPU使用率较高，此时系统态占用达到了23%，说明可能存在大量的系统调用或者中断导致系统态CPU使用率较高。
查看下引擎监控的操作行数
发现此时全表扫描行数并不高。
查看下引擎监控的连接情况
发现此时活跃会话数已达到279个，此实例规格为2C4G，因为CPU只有两个core，同时却有279个会话同时运行，此时CPU会频繁的进行上下文切换，导致CPU的系统态占用增加，降低了CPU实际去执行SQL的时间。此时说明数据库资源已远超目前能提供服务的负载。一般合理的活跃会话数量是当前实例规格CPU数量的2-3倍，例如实例规格为2C4G，性能最高的情况为活跃会话数不超过4-6个，此时CPU使用效率最高，绝大多数CPU资源都用于执行SQL，而不是进行上下文切换或者中断等。
查看DAS中的会话管理，查看当前活跃状态的SQL以及数量。
查看DAS中的性能洞察查看当前具体的SQL分布，以及SQL的等待事件
对于这类情况，需要考虑进行规格的升级，或者降低并发降低活跃会话的数量，保存活跃会话在一个合理的范围内。
