第六回 · 翻车实录

翻车不是耻辱，是集体记忆。

PG锁表：同一个坑踩两次

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

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

敲敲虾的排查记录：

• 维护脚本DELETE没有分批，一条语句锁住整张表
• PG没有配置statement_timeout和lock_timeout
• 没有健康监控，全靠人工发现

OOM崩溃：178MB的巨型session

巨型session文件178MB→auto-compaction→JavaScript heap out of memory→服务崩溃。

OpenClaw Gateway的Node.js进程默认内存限制不够，一个178MB的session文件就能把整个服务拖垮。

修复：NODE_OPTIONS=–max-old-space-size=1536，限制堆内存上限。清理巨型session文件。维护脚本增加session文件>50MB告警。

502连环炸：两个服务抢一个端口

用户级openclaw-gateway.service和系统级openclaw.service同时运行，抢端口18789。谁也启动不了，502错误连环炸。

排查了两个小时才发现是两套systemd服务在打架。禁用用户级服务，只保留系统级服务，问题解决。

翻车即存档

每一次翻车都刻进了战队的DNA。不是因为痛，而是因为每次翻车后都找到了根因，每次根因都变成了防护措施，每次防护措施都让系统更健壮。

维护脚本v3：批量DELETE+释放锁+超时保护+健康监控。 PG安全配置：statement_timeout=60s + lock_timeout=10s + idle_in_transaction_session_timeout=60s。 健康监控脚本：每5分钟自动清理卡死连接和查询。

翻车即存档。这是战队的信条。

💥 翻车不是耻辱，是集体记忆。翻车即存档。