如何排查AWS RDS Postgres 10高CPU瓶颈（基于Performance Insights）

针对你观察到的「Top Databases、Top Applications、Top Session Types和Top Users指标高于SQL查询本身」的情况，说明CPU消耗并非来自单条高负载SQL，而是聚合维度下的批量行为、并发连接或后台进程等因素，可按以下维度逐层排查：

1. 从Top Databases维度切入 #

• 若某数据库的等待/CPU占比显著偏高，先核查该库的并发连接数：切换到Performance Insights的「Connections」维度，确认该库的活跃连接是否持续高位。Postgres每个连接对应一个独立进程，当连接数超过实例CPU核心数或max_connections阈值时，进程上下文切换会大幅增加CPU开销。
• 检查该库的后台维护进程：在Performance Insights中筛选wait_event_type为CPU或IO，同时关联backend_type字段，查看是否有大量autovacuum或analyze进程运行。Postgres 10中，若autovacuum_vacuum_scale_factor等配置不合理，会导致垃圾堆积后集中清理，瞬间占用大量CPU。

2. 从Top Applications维度排查 #

• 定位高占比应用后，确认其连接模式：是短连接频繁创建销毁，还是长连接池复用？短连接的TCP握手、Postgres进程启停会额外消耗CPU，尤其在未配置PgBouncer等连接池的场景下。
• 分析应用的请求特征：是否是大量低消耗小查询的高并发？比如重复执行的SELECT * FROM small_table这类SQL，单条CPU消耗低，但并发量累积后，聚合指标会远高于单条SQL的数值。可将应用维度与SQL维度结合，筛选该应用下的所有SQL，统计重复执行的高频查询。

3. 从Top Session Types维度分析 #

• 区分会话类型是application还是background：
  • 若background会话占比高，重点排查系统后台进程：比如wal writer（WAL生成过快时频繁刷盘会伴随CPU消耗）、checkpointer（执行检查点时整理脏页占用CPU）、stats collector等。
  • 若application会话占比高，查看会话状态字段：是否有大量会话处于idle in transaction状态？这类会话会持有锁，导致后续查询等待轮询，间接增加CPU消耗；若为active状态，则需进一步聚合该类会话的SQL，看是否是批量小查询的并发累积。

4. 从Top Users维度深挖 #

• 定位高CPU占比的用户后，核查其操作类型：是否为超级用户执行批量维护操作（比如批量建索引、数据导入）？这类操作通常不会对应单条高负载SQL，但会持续占用CPU资源。
• 查看该用户的连接行为：是否存在短时间内大量创建连接的情况？若应用未做连接池限制，数百个并发连接会迫使Postgres为每个连接分配进程，加剧CPU上下文切换开销。

补充验证步骤 #

• 结合CloudWatch指标：关联RDS实例的CPUUtilization、DatabaseConnections、CommitLatency等指标，确认CPU高负载时是否伴随连接数激增、事务提交延迟上升等联动现象。
• 导出SQL执行明细：通过RDS的日志导出功能或performance_schema，获取Top用户/应用下的SQL执行记录，验证是否存在高频重复的低消耗查询，或未优化的批量操作。

内容的提问来源于stack exchange，提问作者deagleshot