当实例CPU使用率持续较高时,很容易导致数据库访问响应慢。本文介绍如何定位CPU使用率高的原因以及如何解决这些问题。

查看CPU使用率

对于RDS PostgreSQL实例来说,CPU使用率持续高于80%,通常表明系统处于高负载的情况,并且很可能存在较严重的性能问题。

查看CPU使用率
说明 您可以在控制台监控与报警中的资源监控里查看CPU使用率信息。

基本概念

  • CPU使用率:CPU执行的工作时间的比例,包含了所有符合条件的活动的时钟周期,例如阻塞等待I/O而导致较高的使用率。CPU使用率又被分为内核时间和用户时间。
  • 用户时间:执行用户态(User Mode)程序的时间被称为用户时间。
  • 内核时间:执行系统态(System Mode)代码的时间为内核时间,包含系统调用,内核线程和中断的时间。
  • 上下文切换:内核程序切换CPU让其在不同的地址空间上操作。
  • 中断:由物理设备发送给内核的信号,通常是请求I/O服务。

扫描行高导致的CPU使用率高

  • 现象:

    在控制台的资源监控中可以看到,CPU使用率和操作行数很高。

    CPU使用率操作行数

    通过查看操作行数的详细信息可以发现,数据库中存在大量的全表扫描行,这是导致CPU使用率高的主要原因。此时应该定位到导致该问题的SQL,对其进行优化。

    定位问题SQL
  • 解决方案:通过一键诊断功能定位问题SQL,并对其进行优化。更多信息,请参见RDS PostgreSQL慢SQL问题
    说明 您可以在RDS控制台左侧导航栏中选择自治服务 > 一键诊断,打开一键诊断功能。

活跃会话高导致的CPU使用率高

  • 现象:

    在控制台的资源监控中发现CPU使用率较高,此时系统态占用达到了23%,说明可能存在大量的系统调用或者中断。

    CPU占用率

    通过操作行数可以看到,全表扫描数其实并不高。

    操作行数

    再查看连接,发现此时活跃会话数已达到279个,由于本示例中使用的实例规格为2核4GB,当279个会话同时运行时,CPU会频繁地进行上下文切换,导致系统态占用增加,降低了CPU实际去执行SQL的时间。

    连接
    说明 正常情况下,合理的活跃会话数量应当是当前CPU核数的2~3倍,例如实例规格为2核4GB时,活跃会话数应当维持在4~6个,此时的CPU使用效率最高。
  • 解决方案:考虑进行实例规格的升级,或者降低活跃会话的数量,使其保持在一个合理的范围内。