2核2G轻量服务器两次假死：小内存 VPS 的 OOM 教训与内存预算

背景

我手头有一台 2 核 2G 内存的轻量云服务器，系统盘 40G，跑 Ubuntu。上面陆续装了几样东西：一个定时任务面板、几个自托管小服务、一个浏览器容器，平时还用来跑些轻量实验。单看每一项都不重，加起来却在两个月里把机器拖死过两次：SSH 连不上、面板打不开、所有服务同时失联，最后只能去控制台强制重启。两次的根因都一样——内存耗尽，系统触发了 OOM（Out of Memory）保护，而机器没有配置 swap，连最后一点缓冲都没有。

方案：先算总账，再决定装什么

小内存机器的第一原则是：内存是硬预算，先算总账再上服务，而不是先装满再救火。我的做法分四步。

第一步，列出常驻服务清单并逐项估算内存。定时任务面板、监控面板、自托管站点、浏览器容器，每一项都写下平时占用和峰值占用。浏览器是最容易被低估的一项：一个带图形界面的浏览器容器，峰值能吃掉大半个 G，在 2G 机器上它就是头号大户。

第二步，给每个容器设内存上限。容器不设上限时，单个服务失控就能拖垮整机；设了上限，最坏情况也只是这一个服务自己变慢或重启。浏览器容器我直接卡到 900M 以内，其余服务按实际占用各留上限，总和控制在物理内存的八成左右，留出余量给系统本身。

第三步，定期清理不再用的任务和服务。定时任务面板里一度攒了不少历史任务，有些早已失效还在占资源。我把面板清理到只剩四个亲手配置的常用任务，失效的签到、过期的脚本全部下掉。服务不是越多越好，长期不用的就该删，而不是留着“万一有用”。

第四步，配监控而不是凭感觉。装了一个轻量监控面板加探针，内存、CPU、磁盘一眼可见。以前是服务挂了才知道，现在是内存曲线往上走就能提前看到，先处理再出事。

踩坑

一是以为“轻量服务随便加”。2G 内存听起来不算太小，但容器、运行时、浏览器这些叠加起来非常快。我的教训是：每加一个服务，先问它峰值吃多少内存、和现有服务加起来离上限还有多远，答不上来就先别加。

二是出事只看日志不看内存。第一次假死时我先怀疑网络、怀疑服务配置，绕了一大圈才发现是内存耗尽。后来养成习惯：机器失联先看控制台的资源曲线，内存先见顶就是 OOM，排查顺序应该是资源、进程、配置，而不是反过来。

三是没有 swap 等于没有缓冲。两次假死时机器都没有 swap，内存一满，内核只能直接杀进程，杀到关键进程就整机失联。有 swap 至少能多撑一阵、留出抢救时间。加 swap 已经被我列进待办，正在评估大小与落盘方式；小内存机器上，这一步不该拖太久。

四是把浏览器容器当普通服务对待。图形浏览器加自动化驱动的组合，内存峰值波动很大，不设上限就是一颗定时炸弹。后来我把它的上限、启动时机都单独管起来，只在需要时启动，用完即停，不再让它长期占着内存。

五是重启就算“修好了”。第一次假死后我只重启了机器，没改任何配置，结果同样的场景又来了一次。重启只是恢复服务，不是修复原因；不改内存预算、不设上限、不清任务，下一次假死只是时间问题。

总结

小内存 VPS 的运维核心就一句话：内存是预算，不是余量。先给每个服务估算峰值占用并设上限，总和留出系统余量；定期清理失效任务；用监控面板盯着内存曲线；有条件尽早配 swap 做缓冲。2G 内存完全可以跑一整套轻量自托管服务，前提是每一项占用都算过账、每一项都有上限。机器假死两次之后，我的清单上只留真正每天在用的服务，浏览器容器用完即停，内存曲线也终于平稳了。