系统与基础设施chrisdown.name
为 swap 辩护：常见误解（2018）
In defense of swap: common misconceptions (2018)
2018 — 2025，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇 2018 年的文章由 Chris Down 撰写，针对围绕 Linux swap 的常见误解进行辩护：swap 并不只是内存不够时的补救，它还能回收很少使用的匿名页，把 RAM 留给更常访问的页和文件缓存，并提升系统对临时内存峰值的韧性。文章也讨论内存严重不足时换页抖动、OOM killer 等代价，主张在理解这些权衡后使用 swap。
为什么经久不衰：它把 swap 重新解释为内存与缓存管理工具而非单纯应急手段，正好回应了多年来桌面与服务器上反复出现的卡顿和 OOM 争议。
HN 评论精选
生产服务器与个人开发机不同；桌面有 swap 常导致卡死，无 swap 反而让 OOM killer 快速处理，并提到 systemd-oomd 可能杀掉整个 cgroup。
这篇文章是 2018 年的。我认为它强烈偏向生产环境该怎么做。如果你有一批已知专用工作负载的服务器，我相信启用 swap 对效率有好处：你能跑更多任务、更接近内存上限而仍然安全。出自 Facebook 员工之口，这说得通。但对个人开发机，实际情况完全不同。实践中内存耗尽通常来自两类人为错误：1. 你写了快速泄漏大量内存的代码。2. 你用了 Google Chrome。无论哪种，到了 2022 年 Linux 仍会这样反应：A. 有 swap，系统会完全无响应久到你失去耐心，只能断电重启。B. 没 swap，罪魁祸首会被立即识别并杀死，除了进程被杀，系统完全可用。注意取决于发行版，好的情况 B 最近可能更难实现：systemd-oomd 现在会抢在内核之前急切检测 OOM，一旦检测到就杀掉出问题进程的整个 cgroup！如果你用 gnome 或 kde 还好，否则可能终止你的会话。可以用 systemctl mask systemd-oomd.service 修复。
thxg查看英文原文
(The article is from 2018.) I think the article is strongly from the point of view of what to do "in production". If you have a bunch of servers with known specialized workloads, I can believe that enabling swap is good for efficiency. You can run more tasks and get closer to the memory limit while remaining safe. Coming from a Facebook employee, this makes sense. However, for individual development machines, the pragmatic situation is completely different. The truth is that in practice running out of memory stems from two types of human errors: 1. You wrote some code that leaks lots of memory quickly. 2. You used Google Chrome. In either situation, still in 2022, Linux reacts in the following way: A. With swap, your system becomes completely unresponsive for longer than you have patience for, so you power-cycle it. B. Without swap, the culprit is immediately identified and killed. Your system is perfectly usable, aside from a killed process. Note that depending on your distro, the good case B. may have become a bit harder to achieve recently: systemd-oomd now tries to eagerly detect OOM situations before the kernel, and when it does, it kills the offending process' whole cgroup! If you have gnome or kde, you're good, but otherwise, this may terminate your session. This can be fixed with "systemctl mask systemd-oomd.service"
HDD 上 swap 一旦触发可能让系统一直卡到重启，因为换页导致地址空间碎片化和预读不足；他主张主动、大块换入，并质疑 swap 的收益。
这类文章进一步让我确信 Linux 的低内存处理有严重缺陷，macOS 也是。我对带 HDD 和 swap 的 Linux 机器的体验是：一旦开始换页，不仅会慢到内存被释放、Ctrl-C 生效、OOM killer 运行，而是一直慢到重启。我的推测是进程的虚拟地址空间变成了雷区：匿名内存和文件映射 mmap 现在都有许多按需换入的空洞，预读又不足。每次寻道约 10ms，不需要太多次就该放弃并重启。一旦内存可用，我希望系统主动把 swap 和文件页换入以避免这种情况；如果必须反应式地做，也应该大块进行，每 10ms 寻道至少跟 10ms 读取，约 1 MiB，而不是现在的 4 KiB 之类。默认就该这样。我不认为使用 swap 的决定曾经是好选择。比如文章说可以把很少使用的匿名内存换出以改善缓存命中率，这短视；程序可以写成容忍文件系统 I/O 慢，通常会把 I/O 放在不处理网络或 GUI 的线程，但它们无法现实地容忍任意内存延迟。
scottlamb查看英文原文
Articles like this further cement my belief that Linux's low memory handling is deeply flawed. (macOS's too, btw.) My experience with Linux machines that have HDDs and swap is that once they start swapping, they slow down not only until memory is freed (ctrl-C gets through, OOM killer runs, whatever) but actually until reboot. My theory is that processes' VM space is now a minefield. Both anonymous memory and file-backed mmaps now have many gaps which get paged in on demand with inadequate readahead. With each seek taking ~10 ms, it doesn't take too much of that before you should give up and just reboot. Once memory is available, I'd like the system to proactively page back in both swap and file-backed pages to prevent this. If it does need to happen reactively, it should be in big blocks (each 10 ms of seeking should be follow by at least 10 ms of reading => ~1 MiB, not ~4 KiB or whatever it's doing now). By default. I'm not convinced the decision to use swap is ever a good one. E.g., from the article: > With swap: We can choose to swap out rarely-used anonymous memory that may only be used during a small part of the process lifecycle, allowing us to use this memory to improve cache hit rate, or do other optimisations. This is short-sighted. Programs can be written to tolerate their filesystem I/O being slow. They often take care to do I/O on a particular thread which is not handling network or GUI operations. They can't realistically be written to tolerate arbitrary memory accesses (including program text, stack, and heap) being that slow. It's a stupid idea to potentially slow down the latter to (try to) speed up the former. And programs shouldn't all have to mlockall, which iirc has other bad consequences. (maybe it allocates backing pages for all mappings immediately? even stuff like stack guard pages that's pure waste?) I have written programs to mlock (just) their program text; I'd prefer that weren't necessary either. I prefer that under memory pressure, a task dies promptly. Ideally the "right" task, but really it just has to be better than making the system unusable for a long time. Even if it kills the display server or pid 1 inappropriately, I was probably going to have to reboot anyway, so...
文章讲的是用 swap 腾出 RAM 给热数据，而非支持超大数据集；他用自助仓储比喻说明 swap 的合理用途。
这个讨论串里很少有人读懂文章。重点不是处理大于 RAM 的数据集，而是更好地利用你已有的 RAM：把几乎不会碰的页溢出到磁盘，从而给会碰的页腾出更多 RAM。禁止 swap 就像禁止自助仓储、逼所有人把所有东西都放在家里。当然你能随时拿到奶奶那个半坏的小狗杯垫，但你也更难容纳和找到自己常用东西。如果你发现自己每天都要开车往返自助仓库，那你可能需要更大的房子；但即使你几乎不去，自助仓储也非常有用。
quotemstr查看英文原文
Very few people on this thread read and understood the article. The point isn't working with data sets larger than RAM. The point is making better use of the RAM you do have by taking pages you'll almost never touch and spilling them to disk so that there's more room in RAM for pages you will touch. Banning swap is like making self-storage companies illegal and forcing everyone to hold all possessions in their homes. Sure, you'd be able to get to grandma's half broken kitschy dog coaster that you can't bring yourself to throw away, but you'd also be harder to harder to fit and find your own stuff, the stuff you need all the time. If you find yourself driving to and from the self storage place every day, you probably need a bigger home. But self storage is plenty useful even if you almost never visit it.
桌面内存耗尽时 swap 会让系统长时间无响应，他宁愿用很小 swap 让 OOM killer 尽早介入，并希望看到基准数据。
以我的经验，一个行为异常、RAM 耗尽且还有 swap 可用的 Linux 系统会慢到无法使用。切换到 tty、登录并杀掉肇事进程很容易花上 15 分钟。Xorg 会直接冻住。而且最好你知道是哪个进程，否则祝你能跑起 top。在这问题修好前，我只会给系统配很小的 swap，比如 16GB 内存配 512MB。我宁愿 OOM killer 出手，也不愿按 REISUB 或长按电源键。关于性能说法，最好有些基准测试。
cosarara97查看英文原文
In my experience, a misbehaving linux system that's out of RAM and has swap to spare will be unusably slow. The process of switching to a tty, logging in, and killing whatever the offending process is can easily take a good 15 minutes. Xorg will just freeze. Oh, and hopefully you know what process it is, else good luck running `top`. Until this is fixed, I'll just keep running my systems with very small amounts of swap (say, 512MB in a system with 16GB of RAM). I'd rather the OOM killer kick in than have to REISUB or hold down the power button. Some benchmarks with regards to the performance claims would be nice.
历次讨论
同类还值得读
TTY 揭秘（2008）
The TTY demystified (2008)
经典文章深入剖析了 Unix/Linux 中 TTY 子系统的工作原理，包括线路规程、终端驱动、信号与控制字符等机制。
系统与基础设施上首页 11 次 · 2009–2025linusakesson.net编辑精选为什么 GNU grep 这么快
Why GNU grep is Fast
FreeBSD 邮件列表上一篇广为流传的帖子，解释 GNU grep 为什么快：核心在于 Boyer-Moore 字符串搜索算法配合精心优化的内部循环和 I/O，让程序在搜索时“…
系统与基础设施上首页 9 次 · 2010–2022lists.freebsd.orgXplain：为普通人讲解 X11
Xplain – Explaining X11 for the rest of us
《Xplain》是作者（HN 用户 Jasper_）写的一系列 X11 长文，用他在浏览器中重建的 X11 绘图模型做交互演示，讲解 X11 的绘图模型与窗口系统设计。
系统与基础设施上首页 6 次 · 2013–2020magcius.github.io编辑精选旋风教程：为 Linux 创建极小 ELF 可执行文件（1999）
A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux (1999)
breadbox 写于 1999 年的经典教程，主题是如何为 Linux 手工构造并裁剪出体积极小的 ELF 可执行文件。
系统与基础设施上首页 6 次 · 2007–2025muppetlabs.comPostgreSQL 内部原理
The internals of PostgreSQL
《The Internals of PostgreSQL》是一本免费在线书籍，系统讲解 PostgreSQL 的内部实现，包括查询处理、并发控制、WAL、缓冲区管理等核心机制。
系统与基础设施上首页 5 次 · 2017–2025interdb.jp编辑精选