1G 小内存云服务器的 swap 实战：zram 和磁盘交换到底怎么选

去年双十一囤了一台 1 核 1G 的轻量云服务器，跑一个个人博客、一个反向代理，外加几个定时脚本。机器本身没毛病，就是内存太小，半夜被 OOM killer 干掉过两次：一次是备份脚本和系统自动更新撞了车，一次是反代缓存开得太大。重启能解决问题，但半夜被监控短信吵醒的滋味不好受，我决定把 swap 这件事认真做一遍。

这台机器之前是没开 swap 的。很多人说小内存机器开 swap 是饮鸩止渴，磁盘慢、越换越卡，不如直接加内存。道理没错，但加内存要加钱，swap 不要钱，至少能让进程在内存吃紧时多一条活路。关键是怎么开。

两条路：磁盘 swap 和 zram

摆在我面前的有两条路：传统的磁盘 swap，和 zram。

磁盘 swap 最省事：fallocate 划一个文件，mkswap、swapon，两分钟搞定。代价是云盘的 IOPS 和延迟都不如本地盘，swap 一旦频繁读写，整台机器的响应都会变慢。而且有些云厂商的系统盘 IOPS 是按量算的，swap 抖动起来，账单也跟着抖。

zram 是另一条路：它在内存里划出一块区域做压缩块设备，数据先压缩再存。听起来很矛盾——内存都不够了，还拿内存做 swap？但压缩比通常能到 1:2 甚至 1:3，等于用少量 CPU 换回更多的“有效内存”。代价是压缩解压吃 CPU，好在现在的云服务器 CPU 普遍有富余，博客这种负载根本跑不满。

我的做法：zram 做主力，磁盘 swap 兜底

我的做法是两个都用，但分工不同。

zram 做主力。装 zram-tools，配置很简单：

# /etc/default/zramswap
ALGO=zstd
PERCENT=50

重启 zramswap 服务，free -h 里就能看到一行 zram0，大小是物理内存的 50%，也就是 512M。zstd 算法在压缩率和速度之间比较均衡，我这台机器上实测压缩比大概 2.4:1，这 512M 的 zram 实际能兜住约 1.2G 的匿名页。

磁盘 swap 做兜底，只给 1G，而且把 swappiness 调低：

fallocate -l 1G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
echo "/swapfile none swap sw 0 0" >> /etc/fstab
sysctl -w vm.swappiness=10

swappiness=10 的意思是：内存不到万不得已不去碰磁盘 swap，优先用 zram。zram 满了、内存实在不够了，才去碰那 1G 磁盘交换。这样既保留了最后一道防线，又避免了日常抖动拖慢整机。

压测对比：OOM 之前和之后

然后我做了个简单的压测。开 swap 之前，跑一个峰值占用 1.3G 内存的解压任务，进程直接被 OOM killer 干掉，dmesg 里一堆 “Out of memory: Killed process”。开完之后再跑，同样的任务能跑完，只是慢了约 20%。期间盯着 vmstat 看，zram 的压缩页在涨，磁盘 swap 几乎没动——说明热数据都落在了 zram 里，只有真正冷的数据才会被挤到磁盘上。

一个月跑下来，OOM 一次没再发生。free -h 的日常状态是：物理内存用掉 800M 左右，zram 用了 100 多 M，磁盘 swap 常年是 0。这正是我想要的效果：swap 存在，但平时几乎感觉不到它。

四个坑，提前记下来

第一，zram 的大小别贪多。我一开始设了 100%（1G），结果压缩池本身占内存，机器日常可用内存反而变少了。50% 是个比较稳的起点，2G 以上内存的机器可以再往上加。

第二，swapfile 记得 chmod 600，不然 mkswap 会报权限警告；fstab 里写对，不然重启就丢 swap。

第三，云服务器做整机快照或者镜像时，swapfile 会被算进快照大小，1G 的文件每次快照都占 1G 空间。如果快照按量计费，这笔账要算进去。zram 是内存设备，不存在这个问题。

第四，swap 不是内存，别指望它扛住真正的内存泄漏。我的备份脚本后来还是优化了一版，把并发数降了下来。swap 是安全气囊，不是座椅。

结尾

回头看，之前写 1G 内存优化的那篇聊的是怎么省内存，这篇聊的是内存实在不够时怎么兜底。一个是开源节流，一个是买保险，两件事配合着做，小内存机器才能睡得着觉。

如果你也有一台半夜被 OOM 叫醒过的小机器，不妨按这个顺序试一遍：先上 zram（50%，zstd），再配一个小磁盘 swap 兜底，swappiness 调到 10。花十分钟，换以后半夜不被短信吵醒，我觉得值。