南瓜丶奇迹师很多人看到“交换分区”四个字，第一反应是Ubuntu安装时的那个swap分区选项，或者是在搜索引擎里输入这个词时，突然冒出来一堆EDA工具相关的结果——比如Allegro的swap pin反注。那是芯片设计领域的事，和咱们普通服务器、个人电脑上的Linux内存管理完全不是一回事。但这两者有个共同点：本质上都是在“交换”，把一个东西从原来的位置挪到另一个更合适的位置，腾出空间给重要的事情用。
我们今天要聊的，是Linux世界里那个能救命的交换分区，swap。我接触过不少运维场景，很多系统真正卡死、进程被无缘无故杀掉，都不是因为CPU不够，而是内存见底后连swap都没有，系统只能靠OOM killer随机处决进程。其实，加一块swap并不复杂，但里面的门道挺多——文件还是分区、多大合适、swappiness怎么调、fstab怎么写才不会开机进紧急模式，每一条我都在生产环境里踩过。这篇文章就把完整的添加过程和背后的逻辑一次说清楚。
1. 先判断：你的系统是真的缺内存，还是只是缓存占得多
在动手加swap之前，我建议你先冷静一下。因为我在实际工作中见过太多人一看到内存占用80%以上就慌了，赶紧加swap，结果加完发现一点用都没有，系统该卡还是卡。问题出在判断方式上。
1.1 用free命令看清内存的真实状态
判断内存压力最常用的命令就是free，但很多人是只看一眼Mem那一行的used和free就下结论。这是不对的。要重点看的是available这一列，以及Swap这一行的使用情况。
我以一个典型的线上服务器为例，假设free -h输出如下：
text复制 total used free shared buff/cache available
Mem: 15Gi 7.1Gi 1.2Gi 12Mi 7.6Gi 7.6Gi
Swap: 0Gi 0Gi 0Gi
看到used有7.1Gi，free只剩1.2Gi，很多新手会觉得“内存不够了”。但实际上available还有7.6Gi。这个数值的含义是“在不触发换页的情况下，还可以安全分配给新进程的内存”，它已经考虑到了buff/cache中可回收的部分。这类场景下系统根本不需要swap，你加了swap反而可能导致内核更积极地回收内存页，拖慢整体性能。
反过来，如果available长期低于总内存的10%，甚至经常只剩几百兆，同时Swap那一行又是0，那就是真的内存吃紧。另外还有一个更直接的证据：执行dmesg | grep -i oom，如果返回一堆Out of memory的信息，说明内核已经通过OOM killer杀过进程了，这种时候加swap是立竿见影的。
1.2 系统卡顿和进程被杀才是核心信号
除了看数字，还要看系统行为。上个月我帮一个朋友排查一台跑Java服务的云主机，症状是每天固定下午内存飙高，然后nginx进程偶尔会消失，重启服务后又恢复。查了一圈才发现，这台机器根本没有配置swap，Java的堆内存一到高峰期就把物理内存吃满，内核只能拿OOM killer开刀，而最容易被选中处决的往往是内存占用大、优先级不高的进程。
这里有一个很多教程不会提的观察点：注意一下系统里是否有一个叫kswapd0的内核线程长期占CPU。kswapd0是内核的内存回收线程，如果这个进程频繁唤醒、CPU占用高，说明内核已经感受到内存压力，正在努力把匿名页写回磁盘。在一个完全没有swap的机器上，kswapd0能做的事很有限，它只能回收文件页，一旦文件页也回收完了，就只能触发OOM。所以当你看到kswapd0持续活跃，同时没有swap可用，那基本可以确定：系统需要swap了。
另外可以看一眼/proc/meminfo里的SwapFree和SwapCached。SwapFree表示swap里还未使用的容量，如果它持续为0，说明交换空间已经用满；SwapCached表示swap中最近被读回内存的页，这个值如果一直在涨，说明系统正在频繁换入换出，内存压力非常大。
1.3 哪些场景需要加swap，哪些场景加了也白加
根据我的经验，适合加swap的场景有这么几类：
- 运行Java、JVM类应用，堆内存设置不合理，经常出现内存水位告警
- 内存只有2G到8G的小型云主机，装了数据库、Web服务、中间件等多个进程，峰值内存容易触顶
- 需要休眠的笔记本，suspend-to-disk功能一般需要swap
- 编译大型项目，比如编译Linux内核或Android源码，内存不够时不是报错就是卡死
不适合加swap的场景也有，比如内存本身已经256G以上、主要跑Hadoop或大数据类离线任务，这类场景加swap作用不大，反而会导致部分任务被换出磁盘，引入不必要的IO延迟。再比如容器编排节点，swap的存在会让Kubernetes的节点资源计算失真，导致Pod调度出问题，这类场景一般建议关闭swap。
一句话总结：swap不是内存的替代品，它是一个缓冲区、一个安全网。判断要不要加，核心看两件事，一是available是不是真的长期见底，二是系统是不是已经因为内存不够出过事。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 三种swap方案怎么选：文件、分区和zram
确定了需要加swap之后，接下来就是方案选型。Linux下实现swap主要有三种方式：swap文件、swap分区、zram内存交换设备。很多人一上来就问我哪个好，我只能说各有利弊，选什么取决于你的使用场景。
| 维度 | swap文件 | swap分区 | zram |
|---|---|---|---|
| 创建灵活度 | 极高，随时增删调整 | 低，调整需要改分区表 | 中等，按块设备生成 |
| 性能 | 一般，受文件系统缓存影响，在部分文件系统上有额外开销 | 较好，直接读写块设备，无文件系统开销 | 中等，但受限于CPU压缩能力 |
| 适用场景 | 云主机、桌面、快速扩容场景 | 传统服务器、独立磁盘 | 小内存嵌入式、Android、瘦客户端 |
| 可靠性 | 文件系统损坏会连带影响swap | 独立性好，文件系统崩溃不影响 | 基于内存，重启即清空 |
| 对SSD的影响 | 正常IO写入 | 正常IO写入 | 无直接写入，减少闪存磨损 |
| 创建速度 | 秒级 | 需要分区分卷，较慢 | 快速 |
2.1 swap文件：最推荐的快速方案
swap文件是目前我使用频率最高的方案。原因其实很简单：在云主机上你很难再挂一块额外的盘来做swap专用分区，但你可以随时在一个现有文件系统上创建一个文件，把它格式化成swap格式。扩容和缩容也灵活——swapoff掉，删除或重建文件，再swapon回来就完事了，不用碰分区表。
swap文件唯一的顾虑是性能。它经过文件系统层，受文件系统本身的锁、日志、缓存策略影响。不过在现代Linux上，swap文件通常按块直接映射，只要文件系统是ext4或xfs，性能差距可以忽略。我自己在NVMe SSD上用swap文件跑过压测，和分区方案对比，性能差距在个位数百分比以内。
2.2 swap分区：传统但依然可靠
swap分区是最老牌的方式，在LVM逻辑卷里建一个swap逻辑卷，或者直接在磁盘上分一块区，标记类型为82（Linux swap / Solaris）。它的好处是完全不依赖文件系统，即使根文件系统损坏需要修复，swap依然可以正常使用。还有一个细节：如果你配置了休眠（hibernation），部分发行版要求swap分区必须存在，且大小要覆盖整个内存镜像。
swap分区的问题是不够灵活。比如你买了一块500G的硬盘，当时分了4G做swap，后来内存升级后想把这个swap扩到8G，就得重新分区、调整相邻分区大小，万一中间夹着数据分区，这个操作就是一场灾难。所以我现在一般只在两种场景下用分区：一是纯物理机、磁盘规划一步到位，二是需要休眠支持的笔记本。
2.3 zram：被低估的记忆压缩方案
zram是一个有点特别的存在——它利用内存做交换设备，但会先把要换出的页压缩再存进去。这听起来有点矛盾，内存本来就不够用，怎么还能拿内存做swap？关键在于内存中的数据往往有很高的重复性和规律性，压缩率通常能达到2到3倍。比如一个内存压力很大的系统里，你分配4G的zram设备，实际压缩后可能只占1.5G到2G的物理内存。
zram特别适合小内存设备，比如Android手机、嵌入式路由、轻量级容器。我手里有一台2G内存的软路由，跑Docker和一堆服务，加了一个512M的zram设备后，内存利用率明显提升，运行也稳定很多。但注意，zram会消耗CPU，如果CPU本来就很紧张，用zram可能得不偿失。
2.4 我的方案选择逻辑
如果你问我的默认推荐，我会这样建议：
- 云服务器、虚拟机、桌面电脑：直接上swap文件，大小按内存的0.5到1倍，8G以内通常够用
- 物理服务器、需要休眠的笔记本：建swap分区，最好是LVM逻辑卷，方便以后扩容
- 内存小于4G的嵌入式或边缘设备：用zram，可以显著降低内存不足的风险
不管选哪种，核心原则是一样的：swap的引入是为了缓解内存压力，而不是制造新的瓶颈。如果swap设备所在的磁盘本身IO已经很高，比如系统盘已经跑满，那加swap的收益会大打折扣，甚至让系统更卡。这种时候要么加内存条，要么把swap放到更空闲的磁盘上。
3. swap文件实操：从创建、启用、验证一条龙
方案定了，动手做。这里我以最常用的swap文件方案为例，走一遍完整的操作流程。日常中我用的命令几乎一次成型，但为了把每一步的原理说清楚，我会拆开来写。
3.1 创建swap文件，先搞清楚fallocate和dd的差别
创建一个swap文件，最常见的有两种方式：fallocate和dd。
用fallocate是最快的，因为它只分配文件空间，不逐字节写入：
bash复制# 创建一个4G的swap文件
fallocate -l 4G /swapfile
用dd则是一边写一边分配，速度明显慢，但更“实打实”：
bash复制# 用dd方式创建4G的swap文件
dd if=/dev/zero of=/swapfile bs=1M count=4096 status=progress
我为什么要把这两种方法单独拿出来讲？因为这是一个很经典的坑。fallocate在ext4上工作良好，但在某些文件系统上（比如特定的xfs版本），创建出来的文件可能有空洞——也就是文件系统认为这个文件有4G大小，但实际并没有完整分配底层数据块。当你对它执行mkswap时，可能看到操作成功，但实际使用中swap设备会出现IO错误，严重的时候会导致系统挂起。
所以这里我给出一个比较稳妥的判断标准：文件系统是ext4，用fallocate没问题；文件系统是xfs或者不太确定，建议直接用dd。dd虽然慢，但对于4G到8G来说也就十几秒到半分钟的事，换来的是一份确定性。
创建完之后，先把权限收紧。swap文件里的内容是内存页的数据，可能包含密码等敏感信息，权限过大会被普通用户读取：
bash复制chmod 600 /swapfile
这一步不是可选项。如果你不设600权限，mkswap命令会直接拒绝工作或给出严重警告，因为swap文件权限过于宽松会带来安全风险。
3.2 mkswap和swapon，启用前的最后检查
把文件格式化成swap格式：
bash复制mkswap /swapfile
正常输出大致是：
text复制Setting up swapspace version 1, size = 4 GiB (4294963200 bytes)
no label, UUID=aa4f21ca-6b8b-4c33-9c01-1faa7e6e2a1a
如果mkswap输出里出现insecure permissions或permissions相关字样，说明权限设置有问题，赶紧返回上一步检查chmod。另外注意保存这里输出的UUID值，后面配置开机自动挂载时很可能用到。
然后启用它：
bash复制swapon /swapfile
如果一切正常，没有任何输出。此时用swapon --show查看当前系统里所有的swap设备：
bash复制swapon --show
输出示例：
text复制NAME TYPE SIZE USED PRIO
/swapfile file 4G 0B -2
看到这个就算成功了一大半。再用free -h确认一下Swap那一行不再是0：
text复制 total used free shared buff/cache available
Mem: 15Gi 7.1Gi 1.2Gi 12Mi 7.6Gi 7.6Gi
Swap: 4.0Gi 0B 4.0Gi
到这里swap已经生效了，但只是临时的。重启之后系统不会记得这个swap文件，除非你把它写进/etc/fstab。
3.3 验证swap是否真正缓解了内存压力
启用swap后，我通常不会马上离开，而是再观察几分钟。核心做法是先制造一次内存压力，再观察swap的使用情况。在一个测试用的云主机上，我是这样验证的：
bash复制# 用stress工具制造2G内存压力
stress --vm 1 --vm-bytes 2G --vm-hang 1 --timeout 60
等它跑起来之后，打开另一个终端执行：
bash复制free -h
正常情况下你会看到Swap的used从0开始增长，说明内核正在把部分匿名页换出到swap设备。如果跑完stress之后Swap的used还是0，也不一定代表swap没用，因为系统可能通过回收cache就能满足内存请求，这同样是健康的。真正要警惕的是free显示Swap used不停涨，但同时系统响应明显变慢、磁盘IO拉满——这说明内存缺口太大，swap容量不够或者磁盘太慢，需要进一步调整。
验证完之后，如果你希望这个swap文件在系统重启后依然自动挂载，就要进入fstab的配置环节。这一步看着简单，实际是最容易翻车的，我在下一节单独说。
4. swap分区实操：裸盘分区和LVM两种路径
如果你的场景更适合swap分区，操作路径和swap文件不太一样，但步骤也很清晰。无非是“把磁盘或逻辑卷变成一个类型为82的块设备，然后mkswap、swapon”。我用两种常见的实际场景演示。
4.1 新裸盘直接划分swap分区
假设服务器上有一块全新的磁盘/dev/sdb，你想把整块盘或其中的一部分做成swap分区。先看盘符和分区表：
bash复制lsblk
fdisk /dev/sdb
在fdisk交互界面里，n创建新分区，然后依次指定起始扇区和结束扇区，直接回车使用默认值就是整块盘。创建完成后，重点是t修改分区类型，输入82，这个数字对应的就是Linux swap / Solaris分区类型。
操作完成后，w保存退出。此时再看lsblk，应该能看到一个/dev/sdb1或类似的新分区。接下来和swap文件流程一致：
bash复制mkswap /dev/sdb1
swapon /dev/sdb1
swapon --show
值得一提的是，如果是GPT分区表的磁盘，有些系统上mkswap之前你还需要考虑分区对齐的问题。其实fdisk在创建分区时默认就会按1MiB边界对齐，正常情况下不需要额外处理。但如果你在很老的系统上用过sfdisk或parted手动指定过扇区，最好确认一下blockdev --getalignoff，否则分区对齐不正确会带来随机读写性能损失。
4.2 在LVM卷组里创建swap逻辑卷
用LVM管理服务器磁盘的场景也很常见，尤其是同一块PV里有根分区、数据分区和swap分区的时候，LVM是最灵活的方案。在LVM里添加swap的步骤大致是：
bash复制# 假设你已经有一个卷组叫vg0，创建一个大小为4G的逻辑卷
lvcreate -L 4G -n swap1 vg0
# 格式化为swap
mkswap /dev/vg0/swap1
# 启用
swapon /dev/vg0/swap1
这里就体现出LVM的好处了。以后想扩大swap，只需要先swapoff，然后执行lvextend -L +2G /dev/vg0/swap1，再重新mkswap，整个过程不涉及任何其他分区，也不会影响同一个卷组里其他逻辑卷的数据。我自己的物理服务器就是这种方案，从最初的2G涨到现在的16G，中间调整过四次，一次都没翻过车。
LVM快照也是一个值得提的技巧。如果服务器是生产环境，担心mkswap操作出错，可以在创建swap逻辑卷之前对卷组或已有逻辑卷做一次快照，这样即使操作失误也能回滚。
4.3 用UUID和PARTUUID保证设备路径稳定
不管是用裸盘分区还是LVM，最后都要面临一个问题：重启之后，系统能不能稳定找到这个swap设备？设备路径会漂移，比如/dev/sdb1在插了新硬盘后可能变成/dev/sdc1，这种不确定性是很多运维事故发生的原因。
解决办法是使用UUID或PARTUUID。用blkid查看设备的UUID：
bash复制blkid /dev/sdb1
输出可能长这样：
text复制/dev/sdb1: UUID="4417e8b4-8e3e-4b7e-9f4b-9c9fc969edc6" TYPE="swap" PARTUUID="6f1787ff-8e1e-4f6f-ae24-7e5f87dc8759"
UUID是文件系统或swap格式内部的标识符，PARTUUID是分区表条目的标识符。对于swap分区，我习惯用UUID；对于新式GPT分区表，PARTUUID也可以，但不同发行版对两者的支持略有差异，最简单稳妥的方法还是用blkid输出里的UUID=那一串。
在fstab里你就可以这样写：
text复制UUID=4417e8b4-8e3e-4b7e-9f4b-9c9fc969edc6 none swap sw 0 0
反正记住一条核心原则：不要在fstab里直接写设备路径，除非你能保证这台机器的磁盘拓扑永远不变。一台新服务器和一台生产服务器在这一点上差别很大——新机器你可以偷个懒，生产环境还是老老实实用UUID。
5. 开机自动挂载与fstab那些坑
swap生效之后，下面这件事很多人容易忽视——把swap写进/etc/fstab，否则重启后一切归零。fstab这玩意儿配置错了确实很要命，轻则swap不生效，重则系统在开机过程中直接卡在emergency mode，让你对着一个root shell发呆。
5.1 /etc/fstab的格式与含义
/etc/fstab每一行由六列组成，分别是设备、挂载点、文件系统类型、挂载选项、dump备份标志、fsck检查顺序。对于swap文件或swap分区，典型的写法是：
text复制# swap文件
/swapfile none swap defaults 0 0
# swap分区（以UUID为例）
UUID=4417e8b4-8e3e-4b7e-9f4b-9c9fc969edc6 none swap defaults 0 0
第二列挂载点，对swap来说没有实际意义，用none占位就行。第三列类型是swap，不是ext4也不是xfs，好多人第一次写会写错。第四列选项用defaults够用，也可以写pri=10来设置优先级，多个swap设备时这个设置决定了内核优先使用哪个。第五列和第六列都是0，因为swap不需要dump备份，也不需要开机fsck。
改完文件后，我强烈建议你先执行一次mount -a验证语法和挂载逻辑，而不是直接重启。mount -a会读取fstab并按配置挂载所有未挂载的设备，如果配置有误，命令会直接报错，这样你至少还能在开机状态下去修复。
5.2 最常见的fstab翻车场景和修复方法
我在群里看到过很多次类似的求助：“改了fstab之后重启，直接进emergency mode了，怎么办？”这种情况八成是fstab里写了一个不存在的设备或者UUID写错。系统在启动时找不到对应设备，只能把挂载流程挂起，进入紧急模式等待人工干预。
修复方法也很简单，输入root密码进入emergency shell，然后用vim或nano打开/etc/fstab，把出错的那行注释掉或者修改为正确内容，保存后reboot。但更聪明的做法是防患于未然——在改完fstab后执行：
bash复制findmnt --verify --verbose
这个命令会检查fstab里的每一项是否可解析、设备是否存在、挂载点是否有效。如果有问题，它会明确告诉你哪一行不对，不需要等重启踩坑。还有一个预防措施是你可以在reboot前先执行swapoff掉所有swap设备，然后再mount -a，这样至少能快速验证配置的逻辑正确性。
5.3 如何正确移除swap
有时候swap不需要了，比如给机器加了物理内存，swap就显得多余了。移除swap的顺序不能乱，我的习惯是：
bash复制# 先下线swap设备
swapoff /swapfile
# 或者按设备名下线
swapoff /dev/vg0/swap1
然后从/etc/fstab中删除对应行，最后再删除swap文件或删除逻辑卷：
bash复制rm /swapfile
# 如果是LVM逻辑卷
lvremove /dev/vg0/swap1
有一个关键细节：swapoff的时机。如果当前系统内存非常紧张，swap里已经存储了大量被换出的页面，执行swapoff时内核会尝试把所有swap里的页全部读回内存，这个过程可能导致系统卡顿，甚至触发OOM。所以生产环境里建议在业务低峰期操作，或者先临时增加一个更大的swap设备，再逐步换出去。
6. 让swap真正好用的调优：swappiness与内存回收逻辑
swap加上去≠配置完成。默认配置下，内核的swap行为可能并不符合你的预期。有时候系统明明内存还很充裕，却已经开始大量使用swap，导致应用响应变慢；有时候内存已经快没了，内核却迟迟不肯换出页面，直到OOM爆发。这里面最关键的参数就是vm.swappiness。
6.1 swappiness到底在控制什么
很多教程把swappiness解释为“系统在内存使用率达到多少时才使用swap”，这个说法在早期内核里勉强说得通，但在现代内核里已经不够准确了。准确来说，swappiness控制的是内核回收内存页时，回收匿名页（进程的堆、栈、私有数据，必须写入swap才能释放）与回收文件页（磁盘文件映射到内存的缓存，直接丢弃即可，无需写入磁盘）之间的倾向性。
swappiness的值范围在旧内核里是0到100，新内核（5.8以后）扩展到了0到200。默认值是60。值越大，内核越愿意回收匿名页，也就是更积极地把内存页写入swap；值越小，内核越倾向于回收文件页和回收page cache，尽量少写swap。
举例来说，如果一个系统上跑着MySQL，它用了大量的内存做query cache，这些内存属于文件页缓存，即使丢弃了，下次查询时从磁盘重新读取即可。另一个场景是跑Java应用，它的堆内存属于匿名页，一旦被换出，下次访问时要从swap读回来，速度慢得多。在这类场景下，如果swappiness还是默认60，内核可能会因为文件页缓存不足而分不清轻重，把Java堆的一部分页换到swap里，导致GC停顿时间暴涨。
6.2 不同场景的推荐取值
根据我的经验，不同场景下的swappiness建议如下：
| 场景 | 推荐swappiness | 说明 |
|---|---|---|
| 数据库服务器（MySQL、PostgreSQL等） | 10-30 | 尽量让数据页留在内存，减少数据库的随机读IO |
| Java应用服务器 | 10-20 | 避免JVM堆被频繁换出，降低GC停顿 |
| 普通桌面系统 | 10左右 | 提升桌面响应速度，防止拖沓的换页 |
| 内存充足但偶尔突发内存压力 | 60（默认） | 保持内核默认倾向，减少干预 |
| 存储为机械硬盘的旧设备 | 0-10 | 尽量减少磁盘写换页，因为机械硬盘随机写极慢 |
| 存储为NVMe SSD | 80-100 | 如果内存不够，SSD随机读写快，可以更积极换页，缓解内存压力 |
这里我只给一个大概的方向，具体值还要结合实际压测调。调参的方式很简单：
bash复制# 临时生效
sysctl vm.swappiness=10
# 永久生效
echo "vm.swappiness = 10" > /etc/sysctl.d/99-swap-tuning.conf
sysctl --system
我一般在生产环境会先临时设置，观察一个业务周期，确认没有明显的性能退化和内存告警后再固化到配置文件。
6.3 其他值得关注的内存回收参数
除了swappiness，还有几个参数和swap放在一起调效果更好。
vm.vfs_cache_pressure控制的是内核回收目录项和inode缓存（VFS cache）的倾向性，默认是100。数值越大，回收越积极；越小，越倾向于保留这些缓存。对于大部分场景，默认值就可以。如果你在一个内存相对较小、但目录层级超深的项目里经常做文件操作，可以适当调低到50左右，减少系统调用的响应时间。但不建议调到0，因为那意味着缓存几乎永不回收，内存压力会更集中在匿名页上。
vm.min_free_kbytes这个参数决定内核为紧急分配保留的最小空闲内存。如果系统经常卡在内存分配路径上，可以适当调高这个值，但设置太高会导致可用的page cache变小，降低文件读取性能。这个参数没有固定的推荐值，我一般先看cat /proc/buddyinfo，根据内存碎片情况再决定，默认情况下不需要动。
还有一个vm.overcommit_memory参数，它控制内核是否允许超额分配内存。默认值0表示内核启发式决定是否允许overcommit，1表示永远允许，2表示禁止超过一定比例的overcommit。和swap关系不大，但在内存敏感的应用场景里，误设成1可能导致进程malloc返回成功但实际访问时崩溃，这问题比swap不足还难排查，所以这里顺带提一句，不建议随便改。
7. 我踩过的swap坑和最终结论
文章写到这里，技术内容基本讲完了。最后一节不聊命令，聊几个我在真实环境里遇到的、和swap相关的奇葩问题，都是文档里不太容易看到的东西。
7.1 权限不对导致的mkswap警告
曾经有一次，我在一台机器上创建swap文件，用fallocate创建完成后顺手chown给了某个普通用户，然后直接mkswap。结果是mkswap正常执行，但swapon时报错，而且日志里写的是Unable to read swap header。我排查了半天，最后发现是文件权限和属主的问题——swap文件对属主和权限非常敏感，只要不是root且权限不是600，swapon阶段就可能拒绝加载。后来我养成了习惯：创建完swap文件后先chmod 600再mkswap，并且在mkswap的输出里确认没有警告。
7.2 fallocate在xfs上埋下的雷
另一个坑更隐蔽。有一次帮客户在CentOS上配置swap文件，文件系统是xfs，我用fallocate创建了8G的swap文件，mkswap正常，swapon也正常。但系统运行一段时间后，在高负载场景下出现了swap IO错误，系统日志里满是blk_update_request的异常。后来查下来，xfs在某些版本上对fallocate创建的预分配文件，底层块是未初始化的，读取时可能产生延迟分配和意外错误。解决方法是删掉文件，改用dd重新创建。从那以后，我在xfs上一律用dd，不在这个细节上冒险。
7.3 多个swap设备的优先级问题
一台机器上有多个swap设备时，内核会按优先级顺序使用它们。优先级可以通过swapon -p或fstab里的pri选项设置，取值在-1到32767之间。默认情况下，如果没设置优先级，内核会把它们当作相同优先级处理，轮流使用。这带来一个问题：如果你有一个快速的NVMe盘和一个慢速的机械盘，都做了swap，系统会往两个盘上轮流写swap数据，慢盘就把整体性能拖累了。正确做法是把快盘的swap优先级设置得更高，比如pri=100，让内核优先使用快盘，只有当快盘满了才用慢盘：
bash复制swapon -p 100 /dev/nvme0n1p1
swapon -p 10 /dev/sdb1
7.4 一个小型云主机的实战复盘
最后分享一个实际的案例。一台2核4G的云主机，跑了一个FastAPI应用和PostgreSQL数据库，高峰期内存占用95%以上，频繁出现502错误。云厂商那边换更高规格的实例要加钱，而且也不方便迁移，所以我给他加了4G的swap文件。同时把swappiness调成20，PostgreSQL的shared_buffers调小了一点。之后的一个月里，502错误再没出现过，系统在高峰期内存用完时会自动换页，虽然慢一点，但服务一直在线。这个案例说明一个问题：swap不是银弹，但在预算有限的场景下，它确实是性价比最高的临时解决方案。
我的真实感受是，swap的添加和调优，本质上是在内存、磁盘、CPU三者的性能之间做权衡。少加，内存吃紧时系统不稳定；多加，磁盘IO和CPU都跟着受累。最好的做法不是一劳永逸地设置一个“标准值”，而是定期监控free -h和系统日志，根据业务节奏动态调整。你可以在自己的服务器上先按这篇文章走一遍，把swap文件和fstab配置好，再根据实际情况微调swappiness参数。几次操作下来，你会发现swap其实没有想象中那么神秘，它就是系统给内存压力准备的一个缓冲阀，用好了，能让你的机器稳稳地在线很久很久。