文档

RDS PostgreSQL CPU利用率高问题

更新时间:

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

查看CPU利用率

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

监控与报警页面的标准监控中,查看CPU利用率信息详情请参见查看标准监控

基本概念

  • CPU利用率:CPU执行的工作时间的比例,包含了所有符合条件的活动的时钟周期,例如阻塞等待I/O而导致较高的利用率。CPU利用率又被分为内核时间和用户时间。

  • 用户时间:执行用户态(User Mode)程序的时间被称为用户时间。

  • 内核时间:执行系统态(System Mode)代码的时间为内核时间,包含系统调用,内核线程和中断的时间。

  • 上下文切换:内核程序切换CPU让其在不同的地址空间上操作。

  • 中断:由物理设备发送给内核的信号,通常是请求I/O服务。

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

  • 现象:

    监控与报警页面的标准监控中可以看到,CPU利用率和操作行数很高。

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

    image.png
    说明

    单击每个监控项后的image.png查看各个监控项包含的指标。

  • 解决方案:通过自治服务定位问题SQL,并对其进行优化。更多信息,请参见RDS PostgreSQL慢SQL问题

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

  • 现象:

    监控与报警页面的标准监控中可以看到,CPU利用率较高,此时系统态占用达到了23%,说明可能存在大量的系统调用或者中断。

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

    说明

    正常情况下,合理的活跃会话数量应当是当前CPU核数的2~3倍,例如实例规格为2核4GB时,活跃会话数应当维持在4~6个,此时的CPU使用效率最高。

    image.png
    说明

    单击每个监控项后的image.png查看各个监控项包含的指标。

  • 解决方案:考虑进行实例规格的升级,或者降低活跃会话的数量,使其保持在一个合理的范围内。

  • 本页导读 (1)
文档反馈