企业官网建设流程全解析

1. 从一次线上告警说起：swap 到底在什么情况下会咬人

凌晨两点，监控面板上一条内存使用率的曲线突然拉满，紧接着几台业务节点的响应时间从几十毫秒飙到两秒以上。登录机器一看，free -h显示物理内存还剩一点，但 swap 已经被吃掉了一大半，si/so（swap in/out）的数值在vmstat里持续跳动。这不是内存不够用那么简单，而是系统在疯狂地把内存页换进换出，磁盘 IO 被拖垮，整台机器像陷进泥潭一样。

很多人对 swap 的态度是两个极端：要么觉得它是救命稻草，内存不够就靠它扛；要么觉得它纯粹是性能杀手，恨不得第一时间swapoff关掉。这两种想法都太粗暴了。swap 本质上是操作系统内存管理的一层缓冲，它解决的是"物理内存瞬时不够"和"长期不活跃的内存页占着茅坑"这两类问题。用得好，它是安全垫；用不好，它就是性能黑洞。

这篇内容我打算把 Linux swap 从概念、查看、创建、启停到调优这一整条链路讲透，重点放在启停操作上，因为这是日常运维里最容易被误操作、也最容易踩坑的环节。适合谁看？刚接触 Linux 运维的同学可以当作一份可复现的操作手册；有一定经验的工程师可以重点看调优参数和排查思路那几节，里面有不少我在实际环境里踩出来的经验。核心关键词就三个：swap、启停操作、swappiness，后面会反复围绕它们展开。

先说一个基本认知：swap 不是"内存的替代品"，而是"内存的延伸"。物理内存是内存条，速度快但容量有限；swap 是磁盘上的一块空间，速度慢但容量可以很大。系统把暂时不用的内存页挪到 swap 里，等需要时再换回来。这个"挪"和"换"的过程就是 swap in/out，代价是磁盘 IO。理解了这一点，后面所有的调优和启停决策就都有了依据。

2. swap 的核心机制与方案选型拆解

2.1 swap 空间到底解决了什么问题

要理解 swap 的价值，得先理解 Linux 的内存管理逻辑。Linux 采用的是虚拟内存机制，每个进程看到的是连续的虚拟地址空间，实际映射到物理内存页。当物理内存紧张时，内核的内存回收机制会启动，它会优先回收那些"干净"的页（比如文件缓存，直接丢弃即可），然后是"脏"页（需要写回磁盘），最后才是把匿名页（进程堆栈这类没有文件背景的内存）换出到 swap。

这里有个关键点：匿名页只能换到 swap。如果没有 swap，内核在物理内存耗尽时只能触发 OOM Killer，直接杀掉进程。所以 swap 的第一层价值是防止进程被误杀，给系统一个缓冲的余地。第二层价值是让不活跃的内存页腾位置，比如一个常驻进程启动后加载了一堆代码，之后长期不用，这些页就可以被换出去，把宝贵的物理内存让给真正活跃的业务。

但代价也很明显。磁盘的随机读写速度比内存慢好几个数量级，机械盘更是慢得离谱。一旦系统频繁发生 swap in/out，也就是所谓的"抖动"（thrashing），性能会断崖式下跌。所以 swap 的使用原则是：能不用就不用，但不能没有。它是一个安全网，而不是日常跑道。

2.2 swap 分区还是 swap 文件，怎么选

创建 swap 有两种方式：swap 分区和swap 文件。这两种方式在功能上完全等价，内核处理起来没有区别，但在实际使用中各有取舍。

swap 分区是在磁盘分区阶段就划出来的一块独立分区，类型标记为82（Linux swap）。它的优势是性能略好，因为分区是连续的磁盘块，没有文件系统的开销；劣势是扩容麻烦，一旦划分好，想调整大小就得动分区表，风险高、操作重。传统物理机和早期服务器普遍用这种方式。

swap 文件是文件系统里的一个普通文件，用dd或fallocate创建，然后格式化成 swap。它的优势是灵活，想加就加，想删就删，扩容只需要再建一个文件或者调整现有文件大小；劣势是在某些老文件系统（比如 ext3）上会有碎片问题，性能略逊于分区。现在主流的云主机、容器环境基本都用 swap 文件，因为弹性好。

我的建议很直接：新环境一律用 swap 文件。除非你有极端的性能要求，否则那点性能差异在日常业务里根本感知不到，而灵活性带来的运维便利是实打实的。下面这张表把两者的差异列清楚：

2.3 swappiness 参数背后的取舍逻辑

vm.swappiness是 swap 调优里最核心的参数，取值范围 0 到 100，默认值通常是 60。它控制的是内核倾向于把匿名页换出到 swap 的程度，注意，它不是一个"开关"，而是一个"权重"。

这个参数的工作机制经常被误解。很多人以为设成 0 就完全不使用 swap，其实不是。swappiness=0只是说内核在回收内存时，会尽量避免使用 swap，但在物理内存真正耗尽、且没有其他可回收页的极端情况下，仍然会动用 swap。要完全禁用 swap，得用swapoff，这是两码事。

那这个值怎么定？我的经验是这样：

• 数据库服务器（MySQL、PostgreSQL 这类）：设成1到10。数据库对内存延迟极其敏感，一旦发生 swap，查询性能会剧烈波动。低 swappiness 能让内核尽量保留数据在物理内存里。
• 通用应用服务器：设成10到30。既保留一定的缓冲能力，又不至于频繁换出。
• 桌面环境或内存极度充裕的机器：可以设成60甚至更高，让系统自由调度。
• 容器宿主机：要特别小心，容器内的进程看到的 swappiness 可能受 cgroup 限制，宿主机层面的设置不一定直接生效。

提示：调整 swappiness 是运行时生效的，sysctl vm.swappiness=10立即起作用，但要持久化必须写进/etc/sysctl.conf或/etc/sysctl.d/下的配置文件，否则重启就丢。

3. 查看与评估：动手前先摸清现状

3.1 用 free 和 swapon 快速摸底

动手操作前，第一步永远是看清楚现状。最常用的命令是free：

free -h

输出大概长这样：

total used free shared buff/cache available Mem: 15Gi 9.2Gi 1.1Gi 320Mi 5.1Gi 5.6Gi Swap: 4.0Gi 1.3Gi 2.7Gi

这里要重点看几个数：Swap行的total是 swap 总大小，used是已用，free是剩余。但光看这个不够，还得结合available那一列——它才是"应用真正还能用多少内存"的估算值，包含了可回收的 buff/cache。

另一个命令是swapon，它列出当前激活的 swap 设备：

swapon --show

输出会显示每个 swap 设备的名称、类型、大小和优先级：

NAME TYPE SIZE USED PRIO /swapfile file 4G 1.3G -2

PRIO是优先级，数值越大越优先使用。多个 swap 设备时，内核会先填满高优先级的，再往低优先级写。这个特性在需要临时扩容时很有用。

3.2 用 vmstat 判断是否真的在"抖动"

free只能告诉你 swap 用了多少，但用了多少不等于正在频繁换。一个进程启动时被换出去、之后一直没动，swap 占用高但系统很健康。真正要命的是持续的 swap in/out。这时候要看vmstat：

vmstat 1 5

关注si（swap in，从 swap 读回内存）和so（swap out，从内存写到 swap）两列，单位是 KB/s。如果这两个值长期非零，尤其是持续几百上千，说明系统正在频繁换页，性能已经受影响了。如果只是偶尔跳一下，那属于正常波动。

我一般会连续观察几分钟，配合top或pidstat看是哪个进程在制造内存压力。有时候是某个进程内存泄漏，有时候是缓存策略不合理，找到根因比盲目调 swap 更重要。

3.3 评估当前 swap 配置是否合理

判断 swap 大小是否合适，没有绝对标准，但有几个参考维度。传统经验法则是"物理内存小于 2G 时，swap 设为内存的 2 倍；2G 到 8G 之间设为等于内存；大于 8G 时设为 4G 到 8G"。但这套规则来自机械盘时代，现在参考价值有限。

更实用的判断方法是看峰值内存需求。如果业务在高峰期物理内存使用率长期超过 80%，且 swap 使用量也在涨，那说明内存确实不够，要么加内存，要么合理扩大 swap 作为缓冲。如果物理内存充裕、swap 几乎不用，那 swap 大小只要够兜底就行，4G 到 8G 足矣。

注意：swap 不是越大越好。过大的 swap 会让内核更"放心"地换出内存，反而可能拖慢系统。它的定位是安全垫，不是主力。

4. 创建与启用 swap 的完整实操

4.1 用 fallocate 或 dd 创建 swap 文件

创建 swap 文件有两种主流方式。fallocate速度快，直接分配磁盘块；dd慢一些，但兼容性更好，在某些文件系统上更可靠。

用fallocate创建一个 4G 的 swap 文件：

sudo fallocate -l 4G /swapfile

如果fallocate报错或者创建出来的文件有问题（某些文件系统不支持），改用dd：

sudo dd if=/dev/zero of=/swapfile bs=1M count=4096

这里的bs=1M count=4096就是 1M 乘以 4096，等于 4G。bs是块大小，count是块数量，两者相乘就是文件大小。这个计算过程要心里有数，别拍脑袋写数字。

创建完先确认大小：

ls -lh /swapfile

4.2 设置权限与格式化

swap 文件里可能包含内存中的敏感数据，所以权限必须收紧，只允许 root 读写：

sudo chmod 600 /swapfile

这一步千万别省。权限太松的话，普通用户能读到 swap 文件内容，等于能窥探其他进程的内存数据，这是实打实的安全隐患。

然后把它格式化成 swap：

sudo mkswap /swapfile

成功的话会输出类似Setting up swapspace version 1, size = 4 GiB的信息。如果提示文件正在使用或者大小异常，回头检查上一步。

4.3 启用 swap 并验证

格式化完成后，启用它：

sudo swapon /swapfile

再用swapon --show或free -h验证是否生效。如果Swap行的 total 增加了，说明启用成功。

到这里 swap 只是临时生效，重启后会丢失。要持久化，得写进/etc/fstab：

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

这行的含义是：设备是/swapfile，挂载点写none（swap 没有挂载点），文件系统类型是swap，挂载选项是sw（表示 swap），后面两个0分别是 dump 和 fsck 的选项，swap 不需要它们。

提示：改完/etc/fstab后，强烈建议用sudo mount -a测试一下，确认没有语法错误。fstab 写错会导致系统启动失败，这个坑我见过太多次。

4.4 多 swap 设备的优先级配置

有时候需要临时加一块 swap 应急，或者想把 SSD 和机械盘上的 swap 分开管理。这时候可以用优先级。在/etc/fstab里加pri选项：

/swapfile1 none swap sw,pri=10 0 0 /swapfile2 none swap sw,pri=5 0 0

pri数值越大优先级越高，内核会优先使用高优先级的 swap。这样可以把快的设备（比如 SSD）设高优先级，慢的设低优先级，兼顾性能和容量。

5. 停用 swap 的正确姿势与风险控制

5.1 swapoff 的执行逻辑与内存回流

停用 swap 用swapoff命令：

sudo swapoff /swapfile

或者停用全部：

sudo swapoff -a

这个命令做的事情是：把 swap 里的所有数据页读回物理内存，然后标记该 swap 空间为不可用。注意，是"读回内存"，不是"丢弃"。所以这里有个硬性前提——物理内存必须能装下 swap 里的所有数据。

如果 swap 用了 3G，而物理内存只剩 1G 可用，swapoff会失败，报Cannot allocate memory之类的错误。这时候强行停用是不可能的，因为数据没地方放。解决办法要么先释放内存（停掉一些进程），要么加内存，要么就别停。

5.2 停用前的内存余量评估

停用 swap 前，一定要算一笔账。用free -h看available那一列，这是物理内存里真正可用的部分。再对比 swap 的used。只有当available明显大于 swap 的used时，swapoff才有成功的把握。

举个具体例子：物理内存 16G，available 显示 6G，swap used 是 2G。这种情况下swapoff大概率能成功，因为 6G 的可用空间装得下 2G 的 swap 数据。但如果 available 只有 1.5G，swap used 是 2G，那就悬了，很可能中途失败。

我一般会留出至少 1.5 倍的余量，也就是 available 要大于 swap used 的 1.5 倍，给系统运行和其他进程留点空间。这个余量不是死规定，但保守一点总没错。

5.3 停用 swap 的典型场景

什么时候需要停用 swap？我总结了几类：

• 性能调优：数据库服务器发现 swap 使用导致延迟抖动，决定彻底禁用 swap，强制所有数据留在内存。
• 更换 swap 设备：要把 swap 从机械盘迁到 SSD，先停旧的，再启新的。
• 缩容：swap 文件太大占磁盘，想缩小或删除。
• 排查问题：怀疑 swap 引发性能问题，临时停用做对比测试。

但要注意，停用 swap 不等于解决问题。如果物理内存本来就不够，停用 swap 只会让 OOM Killer 更早动手。停用前想清楚：内存到底够不够？不够的话，停 swap 是治标不治本。

5.4 永久禁用 swap 的完整步骤

如果确定要永久禁用，步骤要完整，别只做一半：

1. 临时停用：sudo swapoff -a
2. 从/etc/fstab里删掉或注释掉 swap 那一行
3. 如果不再需要 swap 文件，删除它：sudo rm /swapfile
4. 验证：重启后free -h里 Swap 行应该全是 0

只做第 1 步的话，重启后 swap 又回来了，因为 fstab 里还写着。这个顺序不能乱，先停用再改配置，避免中间状态出问题。

注意：有些云主机的 swap 是由 cloud-init 或系统服务动态管理的，光改 fstab 可能不够，还得检查相关服务配置。这个因环境而异，遇到问题要顺着swapon --show的结果去追来源。

6. 调优参数与常见问题排查实录

6.1 swappiness 与 vfs_cache_pressure 的配合

除了 swappiness，还有一个相关参数vm.vfs_cache_pressure，默认值 100。它控制内核回收用于目录和 inode 缓存的倾向。值越高，越倾向于回收这些缓存；值越低，越倾向于保留。

这两个参数经常配合调整。比如文件服务器场景，希望保留大量目录缓存加速查找，可以把vfs_cache_pressure调低到 50 左右，同时 swappiness 也调低。而内存紧张的通用服务器，可以保持默认或略调高。

调整方式：

sudo sysctl vm.swappiness=10 sudo sysctl vm.vfs_cache_pressure=50

持久化同样写进/etc/sysctl.d/99-swap.conf这类文件里。我习惯单独建一个配置文件，而不是直接改/etc/sysctl.conf，这样便于管理和回溯。

6.2 swap 相关常见问题速查表

下面这张表是我这些年遇到过的 swap 相关问题汇总，按现象、可能原因、排查方向整理：

6.3 我踩过的几个坑

第一个坑是在内存紧张时贸然 swapoff。有次一台机器 swap 用了 2G，物理内存 available 只有 1.8G，我想着差不多就执行了swapoff，结果命令卡住，系统直接进入假死状态，最后只能硬重启。教训就是余量一定要留够，别卡着临界值操作。

第二个坑是fstab 写错导致启动失败。早期有次手抖把 swap 那行的选项写错了，重启后系统进不了正常模式，只能进救援模式改回来。从那以后我改 fstab 必做mount -a测试，而且改之前先备份。

第三个坑是以为 swappiness=0 就是禁用 swap。这个误解害我在一次性能测试里得出错误结论，后来才搞清楚 0 只是"尽量不用"，真要禁用得swapoff。这两个概念一定要分清。

第四个坑是swap 文件权限没设。有次图快，创建完直接mkswap就启用了，忘了chmod 600。虽然没出安全事故，但被安全扫描工具报了出来，属于低级失误。

6.4 性能敏感场景的 swap 策略

对于数据库、实时计算这类性能敏感的场景，我的策略是：物理内存给足，swap 保留但设低优先级。具体做法是保留一个较小的 swap（比如 4G）作为兜底，把 swappiness 设成 1 到 10，让内核几乎不主动换出。这样既避免了 OOM 直接杀进程，又不会因为频繁换页拖慢性能。

如果内存实在紧张，宁可加内存也不要指望 swap 扛。swap 的定位始终是"安全网"，不是"扩容方案"。把 swap 当内存用，性能一定会教你做人。

7. 写在最后的一点个人体会

swap 这个东西，说简单也简单，几条命令就能搞定；说复杂也复杂，参数、优先级、启停时机、和内存的配合，每一环都有讲究。我自己的习惯是：新机器先规划好 swap，用文件方式，大小按业务峰值内存的 20% 到 50% 预留，swappiness 按业务类型调，然后定期用 vmstat 观察 si/so。这套流程跑下来，基本不会出大问题。

最后分享一个小技巧：如果你不确定某个 swappiness 值是否合适，可以先用sysctl临时改，跑一段时间观察业务指标，确认没问题再持久化。这样比直接改配置文件稳妥得多，改错了重启就恢复，不会留下隐患。swap 的启停操作本身不难，难的是判断"什么时候该动、动多少"，这个只能靠对业务的了解和持续的观察积累。