大多数现代Linux服务器（内存≥16GB、负载稳定）可安全关闭swap，但数据库、JVM应用或需休眠的场景仍需启用；云服务器与K8s宿主机建议禁用，swapfile比分区更灵活但需文件系统支持hole punching，btrfs需谨慎；vm.swappiness=1为生产推荐值，非0不等于禁用swap；swap性能瓶颈在I/O路径，应置于本地NVMe SSD。
swap 分区到底要不要开？
大多数现代 Linux 服务器（尤其是内存 ≥16GB、负载稳定）可以安全关闭 swap，但不是所有场景都适用。关键看是否运行内存敏感服务（如数据库、JVM 应用）或是否需要 hibernation 支持。
常见错误现象：swapon: /dev/sdb1: swapon failed: Device or resource busy —— 往往是该设备已被挂载为文件系统，或已启用其他 swap 区域。
- 桌面环境建议保留 swap（至少等于物理内存），用于休眠和突发内存需求
- 云服务器（如 AWS EC2、阿里云 ECS）若明确不休眠、无 OOM 风险且监控到位，可禁用 swap，避免内核在内存压力下盲目换出冷页拖慢响应
- 容器化环境（Docker/K8s）中，宿主机 swap 会干扰 cgroup 内存限制判断，Kubernetes 官方明确建议
swapoff -a
swapfile 比 swap 分区更灵活，但要注意文件系统支持
swapfile 不依赖磁盘分区，适合 LVM、LUKS 或云盘扩容后动态调整，但要求文件系统支持「hole punching」（即能创建稀疏文件并安全丢弃页），ext4/xfs 均支持，btrfs 则有已知兼容性问题。
典型误操作：直接 dd if=/dev/zero of=/swapfile bs=1G count=4 后立即 mkswap —— 这会触发全盘写入，卡住 I/O；应改用 fallocate。
- 正确创建方式：
fallocate -l 4G /swapfile→chmod 600 /swapfile→mkswap /swapfile→swapon /swapfile - 确保
/etc/fstab中 swapfile 行末尾加sw选项，例如：/swapfile none swap sw 0 0 - btrfs 下避免使用 swapfile，可能引发 kernel panic；必须用时需确认内核 ≥5.0 且启用
swapon --fixpgsz
vm.swappiness 设为 1 不等于禁用 swap
这个参数控制内核倾向将内存页换出到 swap 的积极程度（0–100），设为 0 并不禁止 swap，只是让内核“尽量不换出”，但在真正 OOM 前仍可能触发 swap；设为 1 是生产环境较稳妥的折中值。
错误认知：“设成 0 就彻底不用 swap”——实际测试中，vm.swappiness=0 下，当可用内存跌破 vm.min_free_kbytes 阈值时，内核仍可能换出匿名页以腾出 pagecache 空间。
- 推荐值：
echo 1 > /proc/sys/vm/swappiness（临时）或写入/etc/sysctl.conf的vm.swappiness=1（永久） - 搭配调优：
vm.vfs_cache_pressure=50可减少 dentry/inode 缓存回收压力，间接降低 swap 触发概率 - 注意：容器内无法修改该值，必须在宿主机层面设置
swap 性能瓶颈往往不在大小，而在 I/O 路径
swap 分区或 swapfile 若落在高延迟设备（如机械盘、网络存储、加密卷）上，一次 page fault 可能引入数十毫秒延迟，比内存访问慢 10⁵ 倍以上。此时增大 swap 容量只会恶化性能。
典型症状：dmesg 中持续出现 writeback: balance_dirty_pages: kswapd exhausted 或 iowait 占比异常升高。
- 优先将 swap 放在本地 NVMe SSD 上，避免与业务数据共盘；若只有单盘，至少分到独立逻辑卷（LVM）或不同物理区段
- 禁用 swap 加密（如
crypttab中 swap 映射）除非合规强要求，否则每次换入/换出都多一层加解密开销 - 检查
swapon --show输出中的PRI（priority）列：多个 swap 区域按优先级降序使用，可手动指定高优设备（swapon -p 100 /dev/nvme0n1p2）
swap 的真实成本不是空间占用，而是它把内存管理决策从“是否分配”悄悄转成了“何时阻塞”。很多看似内存充足却偶发卡顿的问题，根源是 swap 在后台默默拖慢了 page reclaim 路径。
