很多便宜 VPS 都是 1C1G、1C2G。刚装系统时看起来够用，一旦同时跑 Nginx、PHP-FPM、MySQL、Redis、Docker 或定时备份，内存就会很快顶满。表现通常是：SSH 变卡、网站偶尔 502、数据库被杀、Docker 容器无故退出，dmesg 里还能看到 Out of memory: Killed process。
这时只说“加内存”当然正确，但不一定现实。对低价年付 VPS、测试机、小博客、轻量 API 服务来说，更实用的做法是：用 ZRAM 提前压缩冷内存，再保留一个小 swapfile 做兜底。这样不能把 1GB 内存变成 4GB，但能显著降低 OOM 的概率，让系统在短时间内存峰值下有缓冲空间。
| 场景 | 建议 |
|---|---|
| 1GB / 2GB 小内存 VPS | 优先启用 ZRAM，再配一个小 swapfile 兜底 |
| 数据库、PHP-FPM 偶尔冲高 | ZRAM 很适合，能减少短峰值导致的 OOM |
| 长时间真实内存不足 | ZRAM 只能缓解，最终还是要降配置占用或升级内存 |
| 磁盘 I/O 本来就很高 | 不要依赖大 swapfile，否则会加重磁盘抖动 |
| SSD 便宜 VPS | swapfile 可以有，但别把它当长期运行内存 |
简单说：ZRAM 是“压缩内存缓冲区”，swapfile 是“磁盘兜底”。 前者快，后者慢；前者更适合低内存 VPS 的日常缓冲，后者适合防止系统瞬间崩掉。
先不要急着改配置。用下面几条命令确认当前瓶颈：
free -h
vmstat 1 10
swapon --show
journalctl -k --since "24 hours ago" | grep -i "out of memory\|killed process"
重点看三件事：
available长期很低，比如只剩几十 MB。vmstat里的si/so持续有值，说明系统频繁换入换出。- 内核日志出现
Killed process，说明 OOM Killer 已经动手。
如果只是偶尔内存冲高，ZRAM 很合适；如果一天到晚都在 swap，那不是调参问题，而是应用配置或机器规格不匹配。
很多教程会把这几个概念混着讲，实际它们不是一回事。
- ZRAM：在内存里创建一个压缩块设备，交换出去的数据仍然放在内存中，但被压缩后占用更少空间。它速度快，适合低内存 VPS。
- Swapfile：把磁盘文件当作交换空间。优点是简单可靠，缺点是慢，容易造成磁盘 I/O 抖动。
- Zswap：内核层面的压缩缓存，常作为磁盘 swap 前的压缩层。它更底层，但排查和解释成本更高。
对大多数 Debian/Ubuntu VPS 用户来说，首选方案是：ZRAM + 小 swapfile。这样既有速度，也有最后兜底。
在 Debian、Ubuntu 上最简单的方式是安装 zram-tools：
sudo apt update
sudo apt install -y zram-tools
编辑配置文件：
sudo nano /etc/default/zramswap
推荐从保守配置开始：
ALGO=zstd
PERCENT=75
PRIORITY=100
如果是 1GB 内存，PERCENT=75 大约会创建 768MB 的 ZRAM 设备；如果是 2GB 内存，则约 1.5GB。不要一上来就配 200% 或 300%，压缩不是免费魔法，CPU 和内存管理也有成本。
重启服务并检查：
sudo systemctl restart zramswap
zramctl
swapon --show
如果看到 /dev/zram0，并且优先级高于普通 swap，就说明 ZRAM 已启用。
即使启用了 ZRAM，我仍建议保留一个小 swapfile。原因很简单：当压缩内存也被打满时，系统还有最后缓冲，不会直接杀进程。
创建 1GB swapfile：
sudo fallocate -l 1G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
写入 /etc/fstab：
echo '/swapfile none swap sw,pri=10 0 0' | sudo tee -a /etc/fstab
这里的 pri=10 是关键：让它优先级低于 ZRAM。系统会优先使用 ZRAM，只有压力更大时才落到磁盘 swap。
检查优先级：
swapon --show
你应该看到 ZRAM 的 priority 高，swapfile 的 priority 低。
vm.swappiness 决定 Linux 多积极地使用 swap。传统磁盘 swap 通常会建议设低一点，比如 10 或 20。但 ZRAM 很快，如果设得太低，系统可能还是等到快 OOM 才开始换出。
对启用 ZRAM 的小内存 VPS，我建议这样开始：
sudo sysctl vm.swappiness=100
写入持久配置：
echo 'vm.swappiness=100' | sudo tee /etc/sysctl.d/99-zram-swap.conf
sudo sysctl --system
如果你发现 CPU 很弱，压缩带来额外负担，可以降到 60；如果内存峰值频繁且 CPU 还有余量，可以试 120。不要盲目照搬某个固定值，重点是观察改动后的实际状态。
配置完成后，用下面几组命令观察 1-2 天：
free -h
zramctl
swapon --show
vmstat 1 10
journalctl -k --since "24 hours ago" | grep -i "out of memory\|killed process"
正常情况下，你希望看到：
zramctl里有压缩数据，但不是长期 100% 填满。swapfile很少使用，或者只在峰值时短暂使用。vmstat的si/so不持续飙高。- 最近 24 小时不再出现 OOM Killer 记录。
如果 ZRAM 长期满、swapfile 也持续增长，说明机器真的不够用。继续加 swap 只会让网站更慢，正确做法是减少服务占用或升级配置。
不对。低内存 VPS 配 8GB swap，往往只是把“进程被杀”变成“整台机器卡死”。swap 是兜底，不是内存扩容。
ZRAM 是内存里的压缩交换设备，重启后会消失，但 swap 本来就不是持久存储。你的业务数据应该在磁盘、数据库和备份里，而不是依赖 swap。
ZRAM 只能缓解压力，不能替代应用调优。MySQL buffer、PHP-FPM worker、Node.js 内存上限、Docker 容器限制都要一起看。
| VPS 内存 | ZRAM 大小 | swapfile | swappiness | 说明 |
|---|---|---|---|---|
| 512MB | 50%-75% RAM | 512MB | 80-100 | 只适合非常轻量服务 |
| 1GB | 75%-100% RAM | 1GB | 100 | 小博客、轻量 API 推荐起点 |
| 2GB | 75% RAM | 1-2GB | 80-100 | WordPress + 小数据库比较合适 |
| 4GB+ | 50% RAM | 1-2GB | 60-100 | 更多是防峰值，不是核心依赖 |
如果配置后发现 CPU 占用变高、延迟变差，可以直接回滚。
关闭 ZRAM：
sudo systemctl stop zramswap
sudo systemctl disable zramswap
删除 swapfile：
sudo swapoff /swapfile
sudo rm /swapfile
sudo nano /etc/fstab
从 /etc/fstab 删除 /swapfile 那一行即可。
对低内存 VPS 来说，最稳妥的策略不是单纯“开 swap”，而是三步走：
- 用 ZRAM 处理短时间内存峰值。
- 用小 swapfile 做最后兜底。
- 用服务级限制控制 MySQL、PHP-FPM、Docker 的常驻占用。
如果你只是偶尔 OOM，这套方案通常很有效；如果你的业务长期依赖 swap 才能活着，那就该升级内存或拆分数据库了。优化的目标不是让 VPS 永远不报错，而是让它在合理负载下稳定、可观察、可回滚。