Swap分区还是Swap文件？配置技巧与性能真相

52JinY 助手

这几年在折腾 Linux 桌面和服务器时，Swap 的话题总能引发争论：要不要配？用分区还是文件？大小怎么定？我自己的结论是：Swap 不是“性能加速器”，而是“极端情况下的减灾措施”，不同场景下取舍完全不一样。

先说分区 vs 文件。早年的建议更偏向独立分区，理由是简单可靠、不受文件系统碎片影响。如今主流内核和文件系统已经把 Swap 文件的随机访问做得很稳，性能差距在机械盘上也不明显，更别提普遍上 SSD 的今天了。Swap 文件的灵活性碾压分区：在线调整容量、临时禁用、在容器/实验环境里按需增减都更顺手。真正需要分区的，多半是极端稳定性诉求的设备（嵌入式、老旧救急系统）或你必须用休眠（hibernate）且想把休眠签名、校验等流程做得更可控的场景。除此之外，我更推荐 Swap 文件。

大小怎么定？别被“内存的两倍”这种老口号绑架。实际看负载画像：
- 纯开发/桌面，内存16-32G，2-4G 的 Swap 文件足够兜底，主要给浏览器和偶发的内存尖峰留条生路，避免直接 OOM。
- 编译/数据科学类工作站，内存64G起步时，给 8-16G Swap 能让偶发峰值不至于把任务打断，但如果你常态压力就高，别指望 Swap 救场，还是加内存。
- 服务器端更务实：内存紧张而延迟又敏感的在线服务，宁可小一点（1-4G）并把 swappiness 拉低，防止核心工作集被换出；批处理/离线任务可以更大一些，容忍换页带来的时间成本。

性能影响方面，最常见的误区是“有了 Swap，系统更快”。事实恰好相反：一旦活跃工作集触发换出，SSD 上也会显著拖慢响应，更别说 HDD。Swap 的意义在于：当你短时间踩过内存红线时，不至于直接被 OOM Killer 清进程。它把“瞬时崩溃”换成“可感知的慢”，给你留了缓冲带。对延迟敏感的服务，这种“慢”也是不可接受的，于是最优解反而是小 Swap + 低 swappiness + 主动内存治理（cgroup 限额、缓存上限、进程内存池）。

关于 swappiness、vfs_cache_pressure 这些内核参数，的确值得动。默认 swappiness=60 偏激进，会更愿意换出匿名页来保留页缓存。桌面我习惯调到 10-20，让交互更稳；数据库/高 QPS 服务甚至下探到 1-5，确保热数据常驻。注意别走极端关掉 Swap（swappiness=0 或直接无 Swap）：在内核需要回收匿名页却

在内核需要回收匿名页却无处可退时，反而更容易触发 OOM，代价比“稍微慢一点”要惨烈得多。合理的姿势是保留一小块 Swap，并把策略调到“保守换出”，而不是彻底断粮。

具体配置上，有几条实践经验：
- 用 SSD 时建议开启 zswap 或 zram 二选一。zswap 作为压缩后备，命中路径更短，适合通用桌面和大多数服务器；zram 则把压缩内存当“伪 Swap”，适合内存紧张、I/O 很差的轻量实例或容器宿主机。别同时大开特开，先测一个，再看命中率和

再决定是否需要叠加另一个。观察压缩比、回写量、以及页面回收是否导致明显的抖动，再做取舍。

- Swap 文件放在哪个设备同样重要。若系统盘是 NVMe，而有一块慢速 SATA HDD，尽量把 Swap 放在快设备上；在多块 SSD 的机器上，分散到 I/O 压力较低的那块盘更稳。文件系统方面

，避免用会引入额外开销或兼容性坑的配置。ext4、xfs 上的 Swap 文件已经很成熟，但要保证文件是连续分配的；创建时用 fallocate 可能得到稀疏/不连续块，建议用 dd 写满再 mkswap，或在 ext4 上配合 chattr +C（禁用 CoW）与 nodiscard 选项，减少碎片和额外写放大。btrfs 虽然也支持 Swap 文件，但对齐、nocow、空间预留等细节出错就会踩雷，除非熟悉其限制，否则更稳妥的是在 btrfs 上用独立 Swap 分区。

- swapon 优先级可以用来表达“分层退路”。比如：zram/zswap 层为高优先级，物理 SSD 上的 Swap 文件为中优先级，HDD 上的 Swap

HDD 上的 Swap 分区/文件为低优先级。这样当内存吃紧时，先走压缩内存，实在顶不住再落到快盘，最后才把最慢的盘当最终缓冲。搭配 vm.watermark_scale_factor 和 psi（Pressure Stall Information）监控，可以更早发现退化并做限流或摘流。

再谈休眠与安全。需要休眠的笔记本，Swap 容量一般至少等于内存的实用峰值（不必死等于物理内存），并留出一定余量给内核与显存映射。加密盘上休眠要关注密钥路径：全盘加密（LUKS）下把 Swap 放在同一卷里最省心；分离的未加密 Swap 可能泄露内存敏感页。服务器侧通常不建议休