PostgreSQL进程CPU占用100%问题排查求助

一、COMMAND列显示数字的含义 #

PostgreSQL后台进程COMMAND列显示的数字，是客户端发送的查询语句哈希值，说明该进程一直在重复执行某条特定查询，结合你的场景，大概率和批量插入/实时插入的SQL逻辑相关。

二、可能的问题环节 #

1. 应用层面潜在问题 #

• 批量插入SQL未优化：如果批量插入未使用COPY或INSERT ... VALUES (...),(...)这类高效写法，而是循环单条插入，再加上表上存在过多索引、触发器，每次插入都会触发大量计算，导致PostgreSQL进程持续高负载。
• 连接/事务管理不当：pg-promise若未正确配置连接池（如最大连接数过高），或批量插入后未正确结束事务、释放连接，会导致PostgreSQL维持无效连接并持续处理残留查询任务。
• 历史数据拉取逻辑异常：每5秒拉取历史数据的逻辑若未正确判断“拉取完成状态”，可能陷入死循环，反复拉取同一批数据并重复插入，迫使PG持续执行插入操作。

2. PostgreSQL内部问题 #

• 表/索引膨胀：频繁插入且未定期清理（如VACUUM）会导致表或索引膨胀，使插入操作的IO、CPU开销剧增，进程长期高负载。
• 异常持久化任务：若存在错误的触发器、存储过程，可能在应用触发后，PG内部持续执行相关任务；但你提到重启PG无效，这种概率较低，仍需排查。

3. 进程重生的核心原因 #

杀死进程后自动再生、停应用也无法终止，说明并非Node.js应用直接触发，而是PG内部存在重复执行的任务，或有其他依赖服务在触发该查询；但重启应用后问题复现，证明应用启动会触发PG生成这类持续运行的任务。

三、排查建议 #

• 开启PG慢查询日志：定位COMMAND列数字对应的具体SQL语句，确认是批量插入还是实时插入的逻辑导致。
• 检查pg-promise连接池：确认连接池max、idleTimeout等参数配置，排查批量插入后是否正确释放连接、结束事务。
• 验证历史数据拉取逻辑：检查分页参数、结束条件是否正确，避免循环拉取同一批数据。
• 临时禁用索引/触发器：关闭表上的索引和触发器，观察CPU负载是否下降，排查附加逻辑的影响。
• 查询pg_stat_activity视图：查看该进程的具体查询内容、事务状态、客户端IP，确认是否来自你的Node.js应用。

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