平台两次宕机求生记

同一个问题出现两次，等于根因未解决。

💥 翻车实录：第一次宕机——措手不及

5月22日，维护脚本执行DELETE操作时锁住了heartbeat_runs表，PG连接全部阻塞，CPU飙到100%，前端一直Loading。

从发现到修复用了3小时。那3小时里，敲敲虾SSH进服务器，top一看load average 15.54——极高。PG 18个active SELECT连接，大量agent start lock timeout警告。

systemctl restart paperclip。服务恢复。但重启只是止血，不是治病。

💥 翻车实录：第二次宕机——同一个坑

5月23日，同样的问题再次出现。这次修复只用了40分钟，但同一个坑踩两次说明根因没有彻底解决。

维护脚本DELETE时没有设超时，自己也被锁住了。相当于自己把自己关在门外，钥匙还在屋里。

🔥 绝地求生：三层防护

根治方案：三层防护，确保同样的问题永远不再发生。

第一层：维护脚本v3

• 批量DELETE（每批5000行+0.1s间隔释放锁）
• 每会话超时保护（statement 60s, lock 10s）
• 单表DELETE最大120s超时

第二层：PG安全配置

• statement_timeout = 60s（杀死超长查询）
• lock_timeout = 10s（锁等待超时）
• idle_in_transaction_session_timeout = 60s（杀死idle-in-transaction连接）
• shared_buffers = 512MB（原128MB）
• work_mem = 8MB（原4MB）

第三层：健康监控

• 每5分钟自动清理idle-in-transaction>60s的PG连接
• 自动清理active>60s的卡死查询
• PG连接数>50告警
• API health检查，502/504/超时自动重启服务

运维脚本也需要单元测试。同一个问题出现两次=根因未解决。