transcript
show notes
服务器还有空闲内存，任务却在启动前被拒绝——问题可能不在 RAM，而在 Linux 严格 memory overcommit 所依据的“承诺地址空间”。这篇文章复盘了一套曾经合理的保护机制，如何在 Java、NumPy、memory mapping 与现代内存分配器普及后，逐渐制造出虚假的内存短缺。
本期将深入解析作者为何放弃严格 overcommit，转而以 systemd/cgroup 的 `MemoryMax` 管理实际内存使用。这不是简单的参数调整，而是一次从“限制理论最坏情况”到“约束可观测真实成本”的容量治理转变。建议结合原文阅读，理解这一决策背后的运维数据与适用边界。
原文链接：
https://utcc.utoronto.ca/~cks/space/blog/linux/StrictOvercommitNoLongerUsing
原文标题：We're no longer using Linux's strict memory overcommit mode
主要内容：
• 严格 overcommit 统计的是进程可能使用的地址空间，而非实际消耗的物理内存，因此可能在程序尚未触碰任何内存前就拒绝其申请。
• 过去计算任务申请多少内存，往往就会实际使用多少；但现代运行时、内存映射和分配器的预留策略，已让“申请量”与真实 RAM 用量显著脱钩。
• 作者在计算服务器上观察到，已承诺地址空间可达到实际内存使用量的数倍，严格模式由此持续拦截本可运行的任务。
• 团队关闭严格 overcommit，改用 systemd 在 `user.slice` 上配置 `MemoryMax`，为系统服务保留必要余量，同时让用户使用真实闲置的内存。
• cgroup 限额会优先触发内存回收；只有回收不足时才在对应 cgroup 内执行 OOM 处理，比预先拒绝虚拟地址空间申请更贴近实际资源成本。
推荐理由：
这是一篇非常扎实的一线运维复盘：它不只告诉你该换哪个 Linux 设置，更揭示了资源治理中一个常见陷阱——当指标失真时，原本的安全策略会悄然转化为利用率瓶颈。对管理共享 Linux 主机、计算集群、SLURM 环境或高内存工作负载的读者而言，文章提供了从观测数据、机制差异到迁移方案的完整思考框架。
---
「Andrej Karpathy的RSS订阅清单」为您精选全球最前沿的AI技术博客文章，深度剖析技术背后的核心洞察。
由 voieech.com 提供技术支持。
