在云原生环境里，CPU 限制（CPU limit）一直被当作保护节点的常规手段。但我们在同一套应用上做了一次对照实验：代码完全相同，CPU 请求（request）也完全相同，唯一区别是有没有设置 CPU 限制。结果令人意外——移除限制后，应用不仅没有被“饿死”，尾部延迟反而更稳，CPU 密集型的启动任务快了约 2 倍，而且还能省下可观的硬件成本。 先说结论：请移除 CPU 限制。限制会在每 100 毫秒的窗口内强制冻结你的应用，哪怕节点上明明有空闲 CPU，应用也可能被反复暂停。保留 CPU 请求就够了，它才是真正的保护机制，能确保每个应用获得自己承诺的那份资源。内存限制则建议保留，因为内存与 CPU 不同，内存超限可能直接杀死进程或拖垮节点，限制内存仍然有效。 为什么限制会导致冻结？内核通过 cgroup 的 cpu.max 文件强制执行限制，以 100 毫秒为一个窗口。比如设置 500m（半核）的限制，意味着每个窗口最多使用 50 毫秒 CPU 时间。一旦配额用完，内核就会把整个应用冻结到下一个窗口。如果应用需要持续计算，它就会频繁被“卡住”，哪怕节点上有大量空闲 CPU 也无法使用。 我们测量了两种配置下的行为。同一条请求路径，有限制时尾部延迟在流量峰值下迅速恶化，而移除限制后延迟曲线保持平缓。应用启动阶段如果包含重计算任务，没有限制时完成时间缩短约一半。这些数据表明，限制带来的负面影响比人们以为的严重得多。 另一个重要发现是资源浪费。大多数集群预留的 CPU 远超实际峰值用量。移除限制后，通过重新调整请求值（right-sizing requests），很多节点可以被缩容下线。我们做了一个示意性的成本模型，按典型云厂商价格估算，每个集群每年能节省数万美元。你只需用自己实际的价格代入，就能算出真实的数字。 当然，移除限制不等于放任不管。你需要做好几件事：第一，保留并合理设置 CPU 请求，让调度器知道每个应用需要多少资源；第二，保留内存限制，防止内存失控；第三，在移除限制后监控应用的实际用量，逐步下调请求值，把释放出的资源转化为真正的成本节约。 我们还整理了一份行动清单：从理论文档（解释 cpu.max 与 cpu.weight 的区别）、CFS 公平分配机制、最坏情况分析，到我们测得的详细结果、噪声邻居问题、常见失败模式，再到针对 .NET 的专项调整和最终效果，整套材料都附在原文链接中。如果你在自己的集群上做同样的实验，可以用同样的方法快速验证：找一个业务低峰期，将某个应用的 CPU 限制移除，观察启动时间和尾延迟变化，再把请求值下调到实际用量的 1.2 到 1.5 倍，持续观测一周，就会看到差异。 总之，CPU 限制是一个被过度使用的旋钮。它带来的“保护”其实很有限，却付出了频繁暂停应用、延迟恶化和浪费资源的代价。正确的做法是：移除限制，保留请求，优配内存，然后让节点真正跑在更高效的轨道上。这不是理论推演，而是我们实测得出的结论。
热门跟贴