云服务器内存告急？5分钟教你用swapfile给Linux系统加个“虚拟内存”应急

凌晨三点，服务器监控突然狂闪——内存占用飙升至95%，MySQL进程被OOM Killer强制终止。作为运维工程师，这种场景你一定不陌生。低配云服务器（比如1核1G的ECS）跑数据库或Web服务时，内存就像早高峰的地铁车厢，稍不注意就会爆满。但临时升级配置需要走审批流程，业务又不能停，这时候 swapfile 就是你的急救包。

与传统的交换分区不同，swapfile就像临时在磁盘上划出一块"虚拟内存"区域。它不需要重新分区，不用重启服务器，甚至不需要root以外的任何权限。下面这个真实案例来自我们团队：某电商大促期间，2核4G的Redis服务器突发流量，通过紧急创建2GB swapfile避免了缓存雪崩，为扩容争取了4小时黄金时间。

1. 快速诊断内存现状

在动手之前，我们需要明确三个关键问题：

• 当前内存剩余多少？
• 是否已存在交换空间？
• 如果是突发流量，预计需要多少额外内存？

第一步 ，用 free -h 查看内存概况。注意 available 列而非 free 列，前者包含了可回收的缓存内存：

$ free -h
              total        used        free      shared  buff/cache   available
Mem:          3.7Gi       2.1Gi       230Mi        16Mi       1.4Gi       1.3Gi
Swap:            0B          0B          0B

第二步 ，用 swapon --show 确认现有交换空间类型。如果输出为空（如上例），说明完全没有交换空间；若显示 TYPE=partition 则是传统交换分区， TYPE=file 才是交换文件：

$ swapon --show
NAME      TYPE SIZE USED PRIO
/swapfile file   2G   0B   -2

小技巧：如果服务器正在频繁OOM，先用 dmesg | grep oom 定位被杀的进程，评估是否值得用swapfile争取时间。

2. 紧急创建swapfile实战

假设诊断结果显示需要2GB临时交换空间，以下是SSD云盘上的最优操作流程：

2.1 快速分配交换文件

传统教程推荐用 dd 命令，但在云环境我更推荐 fallocate ——它直接操作文件系统元数据，速度比写零快100倍：

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile  # 必须限制权限

避坑指南：某些旧文件系统（如ext3）不支持fallocate，此时可用 dd if=/dev/zero of=/swapfile bs=1M count=2048 status=progress

2.2 启用交换文件

通过mkswap初始化后，用swapon立即生效：

sudo mkswap /swapfile  # 输出包含UUID可忽略
sudo swapon /swapfile

验证是否生效：

$ swapon --show
NAME      TYPE SIZE USED PRIO
/swapfile file   2G   0B   -2

$ free -h
              total        used        free      shared  buff/cache   available
Mem:          3.7Gi       2.1Gi       230Mi        16Mi       1.4Gi       1.3Gi
Swap:         2.0Gi          0B       2.0Gi

2.3 配置自动挂载（可选）

如果判断需要长期使用，编辑 /etc/fstab 追加（注意不要换行）：

echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

3. 性能调优与监控

swapfile不是银弹，不当使用反而会拖垮性能。通过这三个维度确保最佳实践：

3.1 调整swappiness

该值（0-100）决定系统使用swap的积极程度。对数据库等延迟敏感服务，建议设为10-30：

# 临时生效
sudo sysctl vm.swappiness=30

# 永久配置
echo 'vm.swappiness=30' | sudo tee -a /etc/sysctl.conf

3.2 实时监控工具

• 基础监控 ： vmstat 1 看 si (swap in)和 so (swap out)
• 详细分析 ： sar -W 1 监控页面交换频率
• 历史趋势 ： cat /proc/vmstat | grep pswp

3.3 SSD特别注意事项

1. 将swapfile放在独立挂载点，避免与业务IO竞争
2. 通过 ionice 降低swap优先级：

   echo 'ACTION=="add", KERNEL=="swap", SUBSYSTEM=="block", ATTR{queue/io_priority}="7"' | sudo tee /etc/udev/rules.d/60-swap-priority.rules
   

4. 后续优化决策树

swapfile只是应急方案，后续应该根据业务场景选择长期对策：

是否需要持续使用swapfile？
├─ 否 → 业务稳定后执行：
│   ├─ sudo swapoff /swapfile
│   └─ sudo rm /swapfile
└─ 是 → 考虑以下优化：
    ├─ 调整swappiness到更低值
    ├─ 将swapfile迁移到高速磁盘
    └─ 用多个小swapfile分散IO压力

最终决策建议：如果swap使用率持续超过30%，就应该优先考虑垂直扩容或应用层优化（比如Redis的maxmemory-policy）。去年我们一个客户用swapfile临时支撑了3天，最终通过优化MySQL的innodb_buffer_pool_size节省了40%内存占用。