Aurora PostgreSQL Serverless V2空闲时CPU占用过高问题排查咨询

针对你遇到的Aurora PostgreSQL Serverless V2多可用区部署下主节点CPU持续55%-60%高负载的问题，我整理了几个额外的排查方向和可能的原因，帮你定位问题：

一、深入排查Autovacuum相关负载 #

虽然你尝试杀死过Autovacuum进程，但它会自动重启处理未完成的清理任务，这大概率是CPU高负载的核心原因：

• 查看死元组分布：执行SELECT relname, n_dead_tup, n_live_tup FROM pg_stat_user_tables WHERE n_dead_tup > 0 ORDER BY n_dead_tup DESC;，确认是否有某张表存在大量死元组，这会让Autovacuum持续运行无法停止。
• 追踪Vacuum实时进度：用SELECT * FROM pg_stat_progress_vacuum;查看是否有正在进行的Vacuum任务，以及它处理的表、完成比例，判断是不是大表清理导致的持续负载。
• 检查Autovacuum配置：通过SHOW ALL LIKE 'autovacuum%';查询autovacuum_vacuum_threshold、autovacuum_vacuum_scale_factor等参数，如果阈值设置过低，会导致Autovacuum频繁触发，持续占用CPU。

二、检查主节点的复制同步开销 #

多AZ部署下主节点需要同步数据到只读节点和备用AZ节点，这部分操作可能悄悄占用大量CPU：

• 查看复制状态：执行SELECT * FROM pg_stat_replication;，重点关注sent_lsn、write_lsn、flush_lsn、replay_lsn之间的差距，判断是否存在WAL积压；同时看write_time、flush_time等指标，确认复制进程是否在持续高负荷工作。
• 分析WAL生成速率：通过SELECT * FROM pg_stat_wal;查看WAL的生成量和写入速率，如果近期有批量数据变更（哪怕当前连接数只有1），主节点可能还在同步历史WAL到从节点，导致CPU占用居高不下。

三、分析后台核心进程（检查点、WAL）的压力 #

检查点和WAL相关进程也是CPU消耗的常见来源：

• 检查点性能分析：执行SELECT * FROM pg_stat_bgwriter;，关注checkpoints_timed、checkpoints_req的数量，如果手动触发的检查点（checkpoints_req）过多，或者定时检查点过于频繁，会导致大量磁盘IO和CPU开销。
• WAL写入开销：查看wal_buffers、wal_writer_delay等参数，过小的wal_buffers会导致WAL频繁刷盘，增加CPU负担；同时观察CloudWatch的WALGenerated指标，确认是否有持续的WAL生成。

四、结合Serverless V2特性排查 #

Serverless V2的自动缩放机制和资源调度可能影响CPU使用率表现：

• 查看ACU实际分配：检查CloudWatch的AuroraACUUsage指标，确认当前主节点的ACU是否处于你设置的0.5-4范围的较低值（比如当前ACU为1，那么55%-60%的CPU使用率其实是用了0.55-0.6个ACU，这种情况如果业务负载低，可能是ACU未自动缩容；如果ACU已经到上限，那就是资源不足）。
• 内部资源调度：RDS后台可能在执行快照、备份、索引优化等维护任务，查看RDS事件日志，确认有没有近期的维护操作；同时看CloudWatch的SnapshotCreationTime等指标，判断是否有后台任务悄悄占用CPU。

五、系统级与监控层面的验证 #

• 利用性能洞察（Performance Insights）：打开RDS控制台的性能洞察，查看CPU消耗的分布情况，明确是哪个进程（Autovacuum、复制、检查点等）占了主要CPU，这能快速缩小排查范围。
• 查看数据库日志：下载postgresql.log，搜索autovacuum、checkpoint、replication相关的日志，看有没有警告、错误或者频繁触发的记录，比如是否有autovacuum: processing table的重复日志，说明Autovacuum一直在高负荷工作。
• 磁盘IO验证：查看CloudWatch的DiskReadOps、DiskWriteOps、DiskQueueDepth指标，如果磁盘IO队列深度高，CPU可能处于iowait状态（看起来使用率高，但实际是等待IO完成），这时候需要排查磁盘性能问题。

可能的核心原因总结 #

1. Autovacuum持续清理大量死元组：即使杀死进程，系统也会重启它来维护数据库健康，这是最常见的原因。
2. 复制同步压力：多AZ部署下主节点需要同步数据到多个节点，WAL生成和发送过程持续占用CPU。
3. 检查点进程频繁触发：不合理的检查点配置或大量数据变更导致频繁检查点，增加CPU和IO开销。
4. Serverless V2资源调度：ACU未及时调整，或者后台维护任务占用资源。

内容的提问来源于stack exchange，提问作者Bibhuti Bhusan Padhi