服务器的响应速度简直就是生命线。不管你是运维老手还是刚入门的Linux爱好者， 肯定都遇到过这种让人抓狂的时刻：明明CPU负载不高，内存也还有剩余，但系统就是慢得像蜗牛爬，SSH连接甚至有时候会卡死不动。你盯着屏幕上跳动的数字，心里那个急啊，恨不得把键盘砸了。很多时候， 罪魁祸首可能并不是你的硬件配置，而是那个默默在后台“捣乱”的家伙——CentOS的swapper机制。

纯正。 今天我们就来聊聊这个颇具争议的话题：到底要不要禁用swapper？这真的能成为提升系统性能、告别卡顿烦恼的灵丹妙药吗？说实话，这并不是一个非黑即白的“是”或“否”的问题，但如果你用对了场景，效果真的会让你惊喜。

什么是Swap？它是天使还是魔鬼？

在CentOS系统中，swapper本质上就是虚拟内存管理的一部分。简单 当你的物理内存不够用的时候，操作系统会把一部分暂时不用的数据从内存里“搬”到硬盘上的一个特定区域去，给急需内存的程序腾出地方。这听起来像是个很贴心的设计，对吧？就像你书桌太小了把不常用的书暂时塞到书架里书桌就能继续干活。

但是这里有个巨大的坑。内存的读写速度是以纳秒计算的，而硬盘的读写速度至少是毫秒级别的。这中间差了十万八千里！一旦系统开始老是使用Swap， 也就是我们常说的“内存交换”， 出道即巅峰。 CPU就得花大量的时间等待硬盘I/O操作完成。这时候，你的服务器负载就会飙升，响应速度直线下降，那种卡顿感简直让人怀疑人生。

所以Swap在内存极度紧缺时是救命稻草，但在内存充足时它可能就是个性能杀手。很多默认的Linux发行版， 包括CentOS，为了“平安”起见， 不妨... 往往倾向于比较激进地使用Swap，这就导致了我们在很多高配服务器上也能看到Swap被占用的情况，这明摆着不是我们想要看到的。

为什么我们要考虑禁用Swap？

你可能会问，既然Linux内核这么聪明，为什么还要我们去干预？ 我们都曾是... 老实说内核的算法虽然通用，但它并不了解你的具体业务场景。

说实话... 想象一下你正在运行一个大型的MySQL数据库或者Redis缓存服务。这些应用对内存的访问速度极其敏感。它们的数据结构设计就是为了在内存中极速运转。如果主要原因是某个后台进程稍微多占了一点内存， 内核就决定把MySQL的一部分冷数据换到Swap里去，等下次MySQL需要查询这部分数据时灾难就发生了。原本几微秒能搞定的事，现在要等几十毫秒甚至更久，对于高并发的业务这简直就是一场灾难。

禁用Swap， 其实吧就是告诉操作系统：“别犹豫，别折腾，我的内存够用，就反而能保证系统的稳定性和响应速度的一致性。毕竟我们要的是快，而不是“虽然没死但慢得要命”，操作一波...。

动手前的准备：看清你的家底

当然 在动手之前，我们得先搞清楚自己手里有多少牌。盲目禁用Swap， 如果内存真的爆了系统会触发OOM Killer， 这事儿我得说道说道。 直接开始杀进程，那场面可能比卡顿更惨烈。

先说说我们需要看看当前的内存和Swap使用情况。打开你的终端， 输入以下命令：

sudo free -h

这个命令会清晰地列出你的总内存、已用内存、空闲内存，以及Swap的相关信息。如果你发现Swap那一栏全是0， 或者Used那一栏非常小， 原来小丑是我。 而且你的物理内存还有大量的空闲，那么恭喜你，你完全可以尝试禁用Swap来榨干硬件的每一滴性能。

除了看总量，我们还得知道Swap到底挂载在哪里。有时候它是分区， 行吧... 有时候是文件。用这个命令看一眼：

sudo swapon --show

这会列出当前启用的所有Swap设备。记下那个不结盟E或者路径， 比如常见的 `/dev/sdb1` 或者 `/swapfile`，接下来的操作就要针对它来进行了。

实战演练：如何彻底禁用Swap分区

好了 既然决定了要提升性能，那我们就别磨蹭。下面这几步操作，将帮你彻底关掉这个“卡顿之源”。 PUA。 为了演示方便，我们假设你的Swap分区是 `/dev/sdb1`。

第一步：临时关闭Swap

这就像拔掉电源插头一样简单。我们使用 `s 不靠谱。 wapoff` 命令来停止使用Swap分区。

sudo swapoff /dev/sdb1

施行这条命令的时候， 如果系统里有大量数据正躺在Swap里系统可能会稍微卡顿一下主要原因是它正在拼命把这些数据搬回内存里。如果你的内存真的不够大， 冲鸭！ 这一步可能会报错或者卡死，那就说明你的硬件条件还不允许这么做，赶紧停下来加内存吧。如果命令顺利施行，没有任何报错，那么恭喜，第一步成功了。

这时候你再运行 `free -h`，应该会发现Swap那一栏的Used变成了0，PPT你。。

第二步：永久禁用——修改/etc/fstab

上面的操作只是临时的， 万一你重启了服务器，CentOS又会根据配置文件自动把Swap挂载起来之前的努力就白费了。我们需要去修改系统的启动配置文件 `/etc/fstab`，加油！。

拜托大家... 用你喜欢的编辑器打开它， 比如vim或者nano：

sudo vi /etc/fstab

在这个文件里你会看到很多行关于文件系统挂载的配置。仔细找找， 梳理梳理。 里面肯定有一行是关于Swap的。它大概长这个样子：

/dev/sdb1       none    swap    sw  0   0

站在你的角度想... 这一行告诉系统：在启动时把 `/dev/sdb1` 挂载为swap类型。我们要做的就是让系统“无视”这一行。最简单的方法就是在行首加一个 `#` 号，把它变成注释。

修改后如下所示：

# /dev/sdb1       none    swap    sw  0   0

保存并退出编辑器。这一步至关重要，千万别手抖改错了其他行， 划水。 否则可能会导致系统无法正常启动。

第三步：验证与重启

基本上... 虽然按道理讲修改完fstab就万事大吉了 但作为一个严谨的运维人员，我们最好还是验证一下。你可以 运行 `swapon --show`，确认此时没有输出任何内容。

为了确保万无一失，建议在业务低峰期重启一次服务器。重启后 直接输入 `free -h`，如果Swap的使用量依然是0， 我始终觉得... 并且 `/etc/fstab` 里的修改也还在那么恭喜你，你已经成功摆脱了Swap的束缚！

禁用后的风险与应对：别高兴得太早

破防了... 看到这里 你可能觉得这就完了系统从此就要飞起来了。且慢，我得给你泼盆冷水。禁用Swap虽然能解决卡顿问题，但它也移除了再说说一道防线。

没有了Swap， 当物理内存耗尽时Linux不会像以前那样慢慢变卡，而是会直接触发OOM Killer。这个机制简单粗暴：它会挑选一个占用内存最多的“倒霉蛋”进程，直接杀掉，瞬间释放内存。如果你的业务是关键服务，被杀掉了那后果可能比卡顿更严重。

所以 禁用Swap是有前提条件的：

场景	建议	原因
物理内存极其充裕	强烈建议禁用	Swap几乎用不到，反而可能被误触发，禁用可提升I/O性能。
高负载数据库/缓存服务器	建议禁用或调整Swappiness	保证数据访问的低延迟，避免硬盘I/O成为瓶颈。
内存捉襟见肘的小型VPS	谨慎禁用	一旦内存溢出， 服务会直接崩溃，Swap能保命。
开发测试环境	随意	反正崩了也不怕，正好测试程序的内存占用情况。

进阶玩法：不一定要完全禁用， 试试Swappiness

如果你觉得完全禁用Swap风险太大，但又不想让系统那么老是去动用Swap，其实还有一个折中的办法， 挽救一下。 那就是调整内核参数 `vm.swappiness`。

这个参数的值范围是0到100。默认值通常是60，意味着内核会比较积极地使用Swap。如果我们把它设为10或者1，甚至0，就告诉内核：“不到万不得已，千万别去碰Swap。”

操作方法也很简单。你可以临时修改：

sudo sysctl vm.swappiness=10

别纠结... 或者永久修改， 在 `/etc/sysctl.conf` 文件中添加一行：

vm.swappiness = 10

内卷。 这样，系统依然保留了Swap作为再说说的救命稻草，但在日常运行中，它会更加倾向于把数据留在物理内存里。这往往是一个比“一刀切”更完美的解决方案。

性能与稳定的博弈

绝了... 回到我们一开始的问题：禁用CentOS swapper功能， 真的能提升系统性能、告别卡顿烦恼吗？答案是肯定的，但前提是你必须拥有足够的物理内存，并且能够承担内存耗尽时进程被杀的风险。

一言难尽。 对于大多数生产环境下的高配服务器， 特别是那些对延迟敏感的数据库应用，禁用Swap或者将Swappiness调至最低，确实是一剂提升性能的良药。它能让你彻底摆脱硬盘I/O带来的随机卡顿，让系统响应如丝般顺滑。

但技术从来都不是教条，不要盲目跟风。在动手之前，请务必用 `free -h` 和 `swapon --show` 仔细审视你的系统状态。记住最好的优化永远是适合自己业务场景的优化。希望这篇文章能帮你做出正确的决定，让你的服务器不再“卡顿”，而是跑得飞快！

---