关键词：OOM、小内存服务器、Linux、Java、Swap、稳定态
适用范围：1核1G ～ 2核2G ～ 4G 云服务器
一、为什么小服务器总是“死得很突然”
如果你用过小规格云服务器，大概率经历过这些瞬间：
网站好好的，突然 502
服务“自己重启”了
日志里什么异常都没有
你甚至怀疑是云厂商的问题
直到有一天，你在系统日志里看到一句话：
Out of memory: Kill process xxxx
这不是 Bug，也不是偶然。
这是 小服务器的宿命问题。
二、什么是“稳定态”，什么是“危险态”
在真正讨论方法之前，必须先建立一个概念：
服务器不是“跑着就行”，而是要跑在稳定态。
1. 稳定态（可以长期运行）
满足以下特征：
available 内存 ≥ 30%
swap 仅少量使用（几十 MB）
CPU 峰值可控
核心进程内存占用稳定、不持续增长
这是可以 7×24 运行 的状态。
2. 危险态（随时 OOM）
只要命中其中几条：
available < 200MB
swap = 0 或 swap 被打满
Java / Node / Python 内存不设上限
服务越跑越慢，但不报错
这时你离 OOM 只差一次请求高峰。
三、小服务器的第一条生存法则：必须允许“缓冲区”存在
很多 OOM 的直接原因不是“内存不够”，而是：
内存用尽时，系统没有任何缓冲空间。
这就是 Swap 的意义
Swap 不是让程序“跑在磁盘上”，而是：
吸收瞬时内存峰值
给系统一个“反应时间”
避免直接触发 OOM Killer
正确的 Swap 使用姿势
Swap 大小：≈ 物理内存（1–2GB）
swappiness：
10
这代表一种态度：
平时不用，关键时刻救命。
四、第二条生存法则：任何服务都必须有“边界”
小服务器最忌讳的一句话是：
“这个服务默认配置就行吧。”
1. JVM 不设上限 = 等待 OOM
在 Java 场景下：
不设
-Xmx就等于允许 JVM 占用全部内存
在 2核2G 服务器上，这是必炸配置。
生存法则：
JVM 最大内存 ≤ 物理内存的 25%～40%
2. 数据库同样需要边界
MySQL / PostgreSQL 默认都会：
尽可能使用更多内存
提升性能
但在小服务器上：
性能优先 ≠ 生存优先
数据库的 Buffer Pool 必须被压缩到“够用即可”。
五、第三条生存法则：插件 ≠ 功能，插件 = 常驻成本
在小服务器上，插件不是“开关”，而是：
常驻对象
监听器
定时任务
内存结构
一个非常残酷但真实的事实：
插件的危害和访问量无关。
哪怕你一天只有几十个访问：
搜索插件
互动插件
AI 插件
都会长期占用内存。
生存法则：
功能优先级 < 生存优先级
能删就删
用时再装
六、第四条生存法则：不要追求“零 swap”
很多“优化教程”会告诉你：
“swap 用了就是慢。”
这是对小服务器非常危险的误导。
正确理解是：
swap 少量使用 = 健康
swap 长期暴涨 = 架构不适合
如果 swap 一直是 0：
你不是优化得好
你是“没有缓冲区”
七、第五条生存法则：用行为判断健康，而不是配置
在小服务器上，结果比配置重要。
三个最重要的观测指标
free -h
ps aux --sort=-%mem | head
top
判断是否稳定，只看这几条：
available 是否长期 > 300MB
核心进程 RSS 是否稳定
swap 是否只在峰值使用
八、从 OOM 到稳定态，我做对了什么
回顾整个过程，真正让我系统稳定下来的，不是某一条命令，而是思维转变：
当我开始问：
“这个服务最多允许用多少？”
而不是：
“它现在用了多少？”
系统就开始变得可控。
九、小服务器的终极生存原则
最后总结成一句话：
小服务器不是用来“压榨性能”的，
而是用来“控制边界”的。
你无法阻止资源有限，
但你可以决定 谁先被限制、谁必须活着。
结语
OOM 不是失败，它是一次提醒。
从那次 OOM 开始，我不再追求“跑得多快”，
而是追求：
跑得久、跑得稳、跑得可预期。
这，才是小服务器真正的生存之道。