Linux SWAP模型实战：从内存瓶颈到swapfile与zram调优

很多人第一次听到“SWAP模型”这个说法，第一反应是Linux里的swap交换空间，还是金融里的利率互换？我在实际排查服务器性能问题时，发现大部分问这个问题的朋友，其实是在纠结一件事：服务器内存不够了，到底该怎么设计交换空间，才能既保证进程不崩，又不至于把磁盘IO拖垮。这个事情的完整解法，就是一套可以复用的SWAP模型。

这篇文章我会直接用实际运维视角，把Linux下SWAP的设计思路、形态选型、参数调优和踩坑记录全部拆开。适合刚接手服务器的新人，也适合被swap问题折磨过的后端开发和运维老手。每个方案我都会给出可复现的操作步骤和计算过程，你照着做就能落地。

1. SWAP模型到底是个啥：抛开概念先看本质

1.1 为什么Linux系统离不开交换空间

交换空间本质上是一块磁盘空间，充当物理内存的溢出缓冲区。当物理内存被进程占满，内核的内存回收机制就会把不常访问的内存页写到磁盘上，腾出物理页给更活跃的数据用。这个过程叫swap out，等进程再次访问这些页时再从磁盘读回来，叫swap in。

有人会问，既然内存不够，为什么不多买点内存，非要搞swap？原因很简单：一是内存成本高，尤其云厂商的内存实例价格并不便宜；二是很多业务存在明显的波峰波谷，晚高峰内存打满，凌晨可能连三分之一都用不到。为了几分钟的峰值去买双倍内存，预算上不划算。这时候swap的价值就出来了，它相当于一个慢速内存的缓冲垫，让系统在内存紧张时不至于直接触发OOM killer乱杀进程。

但swap不是免费的午餐。磁盘速度比内存慢几个数量级，如果内存压力长期存在，系统会花大量时间在换进换出上，表现为load average飙升但CPU使用率不高。有个典型的形容叫“swap颠簸”，意思是内存和磁盘之间疯狂搬运数据，整个系统几乎停滞。

1.2 “模型”二字背后的真正含义

为什么要叫SWAP模型？因为在实际工程里，swap不是简单执行一行swapon就完事，而是由几种形态组合出来的方案：磁盘分区形态、文件形态、压缩内存形态（zram），以及内核参数调优策略。这套东西组合起来，就像搭积木一样成了一套模型，需要根据业务场景来选配。

我见过不少团队直接把云主机的默认swap拿来用，结果数据库服务每隔几天就出现一次性能断层。问题往往不在swap本身，而是没有对业务做内存画像，也没有针对访问模式调内核参数。所以说，理解SWAP模型的核心，不是会敲那几条命令，而是知道每种形态的适用边界和权衡点。

2. 设计自己的SWAP模型：先看清业务内存画像

2.1 给服务器做一次内存体检

你手头任何一台服务器，在决定swap方案前，都应该先看三样东西：总内存大小、常驻内存基线、峰值内存压力。常驻内存基线可以通过free -m连续抓几天数据得到，峰值压力可以通过vmstat 1观察si和so两列是否持续非零来判断。

我自己的习惯是先跑一周的监控，如果si和so只有在极个别时刻才出现非零值，这类业务适合做小容量swap，甚至可以用zram来扛；如果si和so长期交替出现，说明业务内存本身就吃紧，这时候单纯扩大swap没有意义，反而会掩盖内存泄漏问题，应该先查进程的RSS和疑似泄漏点。

这里有一个容易踩的坑：不能只看free命令的第二行，也就是used那一列。Linux会把空闲内存用作页缓存(Page Cache)，在内存紧张时会优先回收缓存页，这部分不算真正的内存压力。所以推荐看available这一列，或者用/proc/meminfo里的MemAvailable字段，它才是内核估算的可用内存余量。

2.2 三种SWAP落地形态怎么选

• swap分区：传统方式，安装系统时单独划分分区，性能相对稳定，适合物理机和老旧系统。缺点是不方便扩容，分区大小固定后想改很难。
• swapfile文件：现代主流推荐方式，在已有文件系统上创建一个文件作为交换空间，扩容方便，可以随时增删，云服务器默认方案几乎都是它。
• zram压缩交换：本质是把一段内存当作块设备，数据先压缩再写入，相当于用CPU换内存空间。非常适合内存吃紧、IO受限的场景，尤其适用于云主机和容器场景。

三种形态的对比我整理了一个表：

分区的性能优势其实只在老内核上明显，现代文件系统加swapfile的差距已经很小。我的建议是云主机和容器直接走swapfile路线，物理机如果追求极致稳定再用分区。zram我放在后面单独讲，因为它的调优逻辑和磁盘swap完全不一样。

2.3 内核参数调优：swappiness不是越大越好

很多人把vm.swappiness理解成“swap使用的优先级”，其实它是内核回收内存时，倾向于回收匿名内存页（也就是进程实际数据）还是文件缓存页的参数，取值范围0到100。默认值是60，意思是内核会相对均衡地处理两种页。

如果业务是数据库等延迟敏感型应用，我建议把vm.swappiness调到10左右，让内核优先回收文件缓存，减少进程被换出到磁盘的概率。反过来，如果跑的是离线计算任务，内存里大部分是临时数据，换出换入对延迟不敏感，可以保持默认值甚至调高一些。

还有一个参数容易被忽视，就是vm.watermark_scale_factor。它控制着内存水位线之间的距离，默认值10表示水位线之间的缓冲区比例。当内存压力增大，内核会提前启动异步回收，这个参数调大可以让回收更激进，但缺点是内存利用率会下降。我通常把数据库服务器的这个值设为125到150，让内核更早介入回收，避免内存被打满后的突然卡顿。

3. 实操：从零构建一套可靠的SWAP模型

3.1 swapfile落地全流程

现代Linux服务器用swapfile方案是最省心的，我下面给出的步骤在CentOS 7到Ubuntu 22.04上都能直接跑。

第一步，先检查当前系统有没有已经启用的swap。

bash复制swapon --show
free -h

如果没有输出，说明还没配置过交换空间。第二步，创建一个固定大小的文件。这里不建议用dd那种全量写零的方式，因为太慢，在较新的内核上用fallocate效率更高，它只分配文件空间而不写数据。

bash复制fallocate -l 8G /swapfile
chmod 600 /swapfile

把权限设为600非常重要，swap文件里会包含内存中的敏感数据，如果权限过宽，普通用户就能读取，安全风险很大。第三步，把文件格式化成交换文件系统并启用。

bash复制mkswap /swapfile
swapon /swapfile

执行完swapon /swapfile后，再用swapon --show确认一下，看到路径和大小显示出来就说明成功了。第四步，写入/etc/fstab实现开机自动挂载，这个最关键，很多人漏了这一步导致重启后swap消失。

bash复制echo '/swapfile none swap sw 0 0' >> /etc/fstab

还要检查一下/etc/fstab中的文件系统挂载顺序。如果/目录是晚挂载的，而swapfile在根文件系统上，就可能出现开机找不到swapfile的情况。我个人习惯在启动脚本里加一层保险，确保根文件系统就绪后再执行swapon。

3.2 zram模型配置实战

zram适合内存吃紧的云主机，尤其适合那种磁盘IO本身就不稳定的实例。配置zram的流程不复杂，但内核必须支持，先加载模块。

bash复制modprobe zram

如果需要开机自动加载，在/etc/modules-load.d/下创建一个配置文件，内容写一行zram即可。接着查看当前有几个zram设备，我一般用动态创建方式。

bash复制zramctl

我的习惯是按物理内存的一半来设置zram的大小。比如2G内存的机器，zram设为1G。因为zram有压缩率，实际能容纳的内存数据量往往是容量的两到三倍。设置设备大小并启用，命令如下：

bash复制echo 1G > /sys/block/zram0/disksize
mkswap /dev/zram0
swapon /dev/zram0

注意这里设置大小用的是字节数还是带单位，不同内核版本对disksize的解析并不完全一致，稳妥起见推荐用不带单位的字节数。设错了后果是实际启用大小和预期对不上，监控时容易困惑。

用zram有个额外收益：它的交换延迟远低于磁盘，即使发生换页，进程卡顿时间也短得多。代价就是CPU占用偏高。我在一台1核2G的云主机上实测过，长时间高负载时CPU的压缩开销占到了5%到8%，对于本来就紧张的1核机器来说还算可以接受。

3.3 监控与验证：怎么确认模型真的生效了

做完配置不是终点，至少要验证三件事：swap已启用、内核识别了参数、实际运行中没有异常换页。第一件事用swapon --show。第二件事用sysctl vm.swappiness查看当前值，确认调整生效。第三件事需要连续观察一段时间。

我常用的命令组合是这样的：

bash复制free -h
vmstat 1 5
cat /proc/meminfo | grep -E 'SwapTotal|SwapFree|SwapCached'

如果SwapFree远小于SwapTotal，说明swap正在被使用中，这不一定有问题；关键看SwapCached这一项，它代表曾经被换出但又被读回内存的页面。SwapCached持续增长，通常说明进程频繁访问被换出的数据，可能存在内存压力。

更细粒度地看，可以用ps -eo pid,comm,args,rss,size查进程RSS，或者用/proc/$pid/status里的VmSwap字段看单个进程占了多少swap。数据库实例如果VmSwap涨到几百MB甚至GB级别，就需要严重警惕了，性能必然受到影响。

4. 常见问题与排查技巧实录

4.1 一重启swap就消失

这个问题百分之八九十都是/etc/fstab没写对。这里有个细节：swapfile用的是绝对路径，如果你在fstab里写的路径和实际文件路径不一致，或者文件权限变了，开机就会静默失败。排查方式很简单，直接看systemctl的启动日志里有没有swapon相关的报错，或者手动执行swapon -a看有没有提示。

另一个容易被忽略的场景是云主机的系统盘是自动挂载的，但挂载顺序晚于swapfile挂载操作。这种情况可以改用systemd的挂载单元依赖，或者在rc.local脚本里延迟执行swapon -a，具体用哪种取决于发行版。

4.2 swappiness设置了没效果

我遇到过在/etc/sysctl.conf里写了vm.swappiness=10，sysctl -p也执行了，cat查值时却依然是默认值。这种一般是安装了一些云管控组件或者systemd服务覆盖了内核参数。解决办法是检查/etc/sysctl.d/目录下的其他配置文件，后加载的配置会覆盖先加载的。还有一个极端的场景是容器环境，容器自己镜像里的sysctl配置和宿主机是隔离的，你在宿主机上改并不会对已经运行的容器生效。

4.3 swap用满了但内存还很充裕

这个现象在低内存机器上经常出现。原因很可能是内核回收文件缓存时，把一些进程的匿名页也顺手换出了，尤其是当swappiness值偏高时。另一个常见因素是NUMA架构。在NUMA机器上，每个CPU有自己本地内存，如果进程绑定到了某个NUMA节点，而该节点的内存耗尽，即使其他节点内存充裕，内核也会优先把该节点的页换出到swap，而不是做远程内存分配。

这种问题不太容易从全局free -h上看出来，得依赖numastat命令观察各节点的命中率。这算是我踩过最隐晦的坑，花费了不少时间才定位到原因。

4.4 敏感业务被swap拖垮怎么办

数据库、Redis这类延迟敏感型服务，理想的状况是尽量不换出。除了调低swappiness以外，还有一个更硬核的手段：直接在等等，这部分也值得展开说，Linux的mlock机制可以把进程内存锁在物理内存里，禁止被换出。对于关键服务，用mlockall或配置里的锁定内存选项，可以实现硬性防护。

拿MySQL来说，可以在配置文件里加memlock=1，前提是给启动用户分配CAP_IPC_LOCK能力。Redis的maxmemory策略配好后，再用mlock限制，基本就能杜绝关键数据页被换出。不过要提醒一句，内存锁只能保证不被换出，如果物理内存确实不够，进程还是会被OOM杀掉，使用这个方案前一定确保内存容量有足够余量。

我把书面上容易遇到的问题整理成一张速查表，方便直接排查：

如果你服务器上有跨NUMA访问敏感服务，建议把swap回收优先级也同步调整。用/proc/$pid/oom_score_adj设定OOM保护值时，顺便检查/proc/$pid/numa_maps，这两个因素叠加起来才是完整的防护方案。

5. 一点压箱底的经验

我在多次运维实战中摸索出的一个重要原则是：SWAP模型不是配完就一劳永逸，而是一套需要持续观察和迭代的方案。尤其云主机的规格可能随时变化，内存从4G升到8G后，旧的swap容量和参数不一定还合适，需要重新计算水位线和容量配比。我自己的做法是每次变更后连续观测两周，记录高峰期的si、so和SwapCached趋势，再决定要不要把swappiness微调几个点。另外，sysctl参数在/etc/sysctl.d/下单独建一个文件管理，比全部堆在/etc/sysctl.conf里更清晰，方便回溯每次变更的原因。这套方法实践下来，服务器因为内存问题引发的故障率能降到一个极低的水平。