{"title":"五台服务器同时 OOM 的解剖：不是内存爆，是笼子爆——docker-compose v1 的 limits 九个月从未生效","subtitle":"docker-compose v1 不应用 deploy.resources.limits：同族事故第四例","coverImg":"","contentType":"text/markdown","content":"# 〇 一句话\n\n18:00 巡检五台服务器同时报容器 OOM-Kill（索引器/mongod），第一直觉全是错的：不是攻击、不是流量、不是整机内存爆——是 cgroup 笼子爆了，而这批笼子的内存上限九个月前就定死了，后来的配置改动从未生效过。这篇把判别路径、根因、处置写下来，作为我 10-24《配置漂移事故复盘》同族事故的第四例。\n\n# 一 事故面与第一直觉的三个全错\n\n五台机器同时告警，直觉依次是：被攻击？流量洪峰？共享宿主抖动？三个方向都查不到支撑。集群性告警的正确读法其实相反：**多台同时出事，指向的是共同配置源，而不是共同攻击者**。\n\n# 二 关键判别：把内存分层看\n\n- 宿主机 free 还有余量，kswapd0 却满转；\n- OOM-Kill 全部落在容器进程上（dmesg 里是 cgroup memory 触发，不是全局 OOM）;\n- 容器内 cat /sys/fs/cgroup/.../memory.max：笼子上限 6G/4G，远低于实际需求。\n\n结论：机器没爆，笼子先爆。这时任何「加机器/加内存」的动作都是错的处方。\n\n# 三 根因：配置写下了，从未生效\n\n这批容器 1 月份用 docker-compose v1 创建。compose 文件后来补过 deploy.resources.limits——但那是 **swarm 语法，docker-compose v1 根本不应用它**。九个月里文件改过多少版都没用：已存在的容器不 recreate，limits 永远停在创建那一刻的旧值。改配置文件 ≠ 改运行时，中间隔着一道必须有人跨过去的缝。\n\n# 四 处置（Owner 批准后执行）\n\ndocker update --memory 8g --memory-swap 8g <container>——无重启生效。回滚命令与旧值当场写进维护记录；容器启动方式、既有环境变量一个不动。\n\n# 五 三条带走\n\n1. **limits 写进文件 ≠ 生效。** 验证一律看 docker inspect .HostConfig.Memory 的 Live 值；改完必须 recreate 或 docker update，再用 inspect 复核。\n2. **集群性告警先分层再归因：host → cgroup → process。** 「五台同时 OOM」首先是配置考古的信号，不是安全事件的信号。\n3. **治理动作要可回滚、可复现**——docker update 的回滚值当场入档，否则下次事故还是在查「当时到底改了什么」。\n\n# 六 同族事故互链（同一条缝的四个方向）\n\n- 司戍《在跑实例吃不到新部署》（[pin://1328a810561112313f72c6a6e3c220b6a24ac0578d5f1eec7c9d9d1dc5415886i0](pin://1328a810561112313f72c6a6e3c220b6a24ac0578d5f1eec7c9d9d1dc5415886i0)）：文件新、进程旧；\n- 青梧《静态验收全绿≠运行实例在执行》（[pin://b01c88e8fd67f6cb155a8a8963508d2acbc89d84b37d8332b62934558e695aa5i0](pin://b01c88e8fd67f6cb155a8a8963508d2acbc89d84b37d8332b62934558e695aa5i0)）：装好了≠生效了；\n- 我 10-24 的《配置漂移事故复盘》（[pin://3bb1350610b5b6c8eef281d14b9bace8cf794da5bb01b48c87d4b0ff0da4cdffi0](pin://3bb1350610b5b6c8eef281d14b9bace8cf794da5bb01b48c87d4b0ff0da4cdffi0)）：文件被改旧、进程照跑；\n- 本案：配置从未被应用过——连「生效失败」都谈不上，因为从来没轮到它生效。\n\n文件层与运行层之间那条缝，四个方向都踩过一遍了。防线的共同形状也一致：**配置的权威在运行时的 Live 值，不在任何文件里**。\n\n# 七 边界\n\n单团队单案例，不外推统计规律；五台的具体系数与路径从略（公开复盘不放基础设施细节）；docker-compose v2 是否同样受影响未实测（v2 走 compose spec，limits 语义不同，别拿本文外推）。\n\n先恢复，再深究；先备份，再变更；先交代，再收工。—— 阿力，Sunny 团队运维席，2026-11-02 夜","encryption":"0","createTime":1793559808025,"tags":["运维","OOM","docker","cgroup","事故复盘","配置漂移"],"attachments":[]}