当实例CPU利用率持续较高时，很容易导致数据库访问响应慢。本文介绍如何定位CPU利用率高的原因以及如何解决这些问题。
查看CPU利用率
对于RDS PostgreSQL实例来说，CPU利用率持续高于80%，通常表明系统处于高负载的情况，并且很可能存在较严重的性能问题。
在监控与报警页面的标准监控中，查看CPU利用率信息。详情请参见查看标准监控。
基本概念
CPU利用率：CPU执行的工作时间的比例，包含了所有符合条件的活动的时钟周期，例如阻塞等待I/O而导致较高的利用率。CPU利用率又被分为内核时间和用户时间。
用户时间：执行用户态（User Mode）程序的时间被称为用户时间。
内核时间：执行系统态（System Mode）代码的时间为内核时间，包含系统调用，内核线程和中断的时间。
上下文切换：内核程序切换CPU让其在不同的地址空间上操作。
中断：由物理设备发送给内核的信号，通常是请求I/O服务。
扫描行高导致的CPU利用率高
现象：
在监控与报警页面的标准监控中可以看到，CPU利用率和操作行数很高。
通过查看操作行数的详细信息可以发现，数据库中存在大量的全表扫描行，这是导致CPU利用率高的主要原因。此时应该定位到导致该问题的SQL，对其进行优化。
说明单击每个监控项后的
查看各个监控项包含的指标。解决方案：通过自治服务定位问题SQL，并对其进行优化。更多信息，请参见RDS PostgreSQL慢SQL问题。
活跃会话高导致的CPU利用率高
现象：
在监控与报警页面的标准监控中可以看到，CPU利用率较高，此时系统态占用达到了23%，说明可能存在大量的系统调用或者中断。
通过操作行数可以看到，全表扫描数其实并不高。再查看连接数，发现此时活跃会话数已达到279个，由于本示例中使用的实例规格为2核4GB，当279个会话同时运行时，CPU会频繁地进行上下文切换，导致系统态占用增加，降低了CPU实际去执行SQL的时间。
说明正常情况下，合理的活跃会话数量应当是当前CPU核数的2~3倍，例如实例规格为2核4GB时，活跃会话数应当维持在4~6个，此时的CPU使用效率最高。
说明单击每个监控项后的
查看各个监控项包含的指标。
解决方案：考虑进行实例规格的升级，或者降低活跃会话的数量，使其保持在一个合理的范围内。