Ubuntu服务器内存告急？5分钟搞定Swap分区扩容（附性能优化小技巧）

Ubuntu服务器内存告急？5分钟搞定Swap分区扩容（附性能优化小技巧）

最近在帮几个初创团队做服务器运维支持，发现一个挺普遍的现象：很多开发者朋友在本地开发环境跑得好好的应用，一部署到云服务器上，内存使用率就直线飙升，甚至直接把进程给“杀”了。尤其是在跑MySQL、Redis或者用Docker部署了几个微服务之后，服务器内存更是捉襟见肘。这时候，一个配置得当的Swap分区，往往能成为救急的“缓冲垫”，给系统争取到宝贵的反应时间，避免服务直接崩溃。

Swap，也就是我们常说的虚拟内存或交换分区，它的本质是当物理内存（RAM）不够用时，系统会将一部分暂时不活跃的内存数据“交换”到硬盘上，腾出RAM空间给更紧急的任务使用。虽然硬盘的读写速度远不及内存，但在内存突发性不足的场景下，它确实是一道有效的安全防线。今天，我们就抛开那些教科书式的理论，直接从实战出发，聊聊在Ubuntu服务器上，如何快速、安全地扩容Swap，并且根据你的实际负载，把它调校得更高效，而不是简单地一开了之。

1. 理解Swap：不只是“内存不够”的备胎

在动手之前，我们得先搞清楚Swap在现代服务器运维中的真实定位。很多人把它视为性能杀手，认为一旦用上Swap，系统就会卡顿不堪。这种观点其实有些片面。Swap的作用更像是一个系统内存压力的“泄压阀”。

Swap的核心价值体现在几个方面：

• 防止OOM Killer误杀：Linux内核在物理内存耗尽时，会启动“Out-Of-Memory Killer”来强制终止进程以释放内存。有了Swap，系统在触发OOM之前，就有了一个缓冲地带，能有效避免关键服务（比如你的数据库）被意外终止。
• 容纳不活跃的内存页：系统中有大量内存是被分配了但长期不用的（比如一些守护进程初始化后占用的内存）。把这些“冷数据”移到Swap，可以释放出宝贵的物理内存给真正活跃的进程使用。
• 支持休眠（Hibernate）：对于桌面系统，休眠功能需要将内存完整镜像保存到Swap。服务器虽然通常不休眠，但这个机制说明了Swap可以存储完整的内存状态。

当然，Swap不是万能的。它的性能瓶颈在于磁盘IO。一个频繁进行Swap交换（Swapping）的系统，其性能必然会受到严重影响，此时真正的解决方案是增加物理内存或优化应用内存使用。因此，我们的目标不是依赖Swap，而是合理配置Swap，让它只在关键时刻、以最小的性能代价发挥作用。

2. 快速诊断：你的服务器真的需要更多Swap吗？

盲目扩容Swap可能适得其反。我们先花一分钟，用几个命令看看系统的真实内存状况。

打开你的终端，连接上服务器。第一个必看的命令是 free -h。-h 参数会让输出以人类易读的单位（G、M）显示。

free -h

你会看到类似下面的输出：

total used free shared buff/cache available
Mem: 3.9Gi 1.2Gi 1.5Gi 16Mi 1.1Gi 2.4Gi
Swap: 2.0Gi 0.0Gi 2.0Gi

这里需要关注几个关键数据：

• available：这个值比 free 更有参考意义，它表示系统估计的、可供启动新应用程序而无需交换的内存大小。如果这个值长期很低（比如小于总内存的10%），就需要警惕。
• Swap used：Swap的使用量。如果这个值持续大于0，并且还在缓慢增长，说明物理内存已经不够用，系统开始动用Swap了。

但 free 命令看的是瞬时状态。要了解趋势，我们需要 vmstat。运行下面的命令，每隔2秒刷新一次，观察 si (swap in) 和 so (swap out) 两列。

vmstat 2 5

这个命令会采样5次，每次间隔2秒。如果 si 和