在高性能微服务容器中，不建议硬限制swap上限，因其本质是“内存+swap”总量上限且会严重损害低延迟特性；应改用--memory=2g（硬限）、--memory-reservation=1.6g（软保障）、--memory-swap=2.2g（仅200mb swap缓冲）组合策略，并调低swappiness至1，以降低换页、避免突刺式oom。
在高性能微服务容器（尤其是 Pod 中）里，不建议用 cgroup 直接硬限制 swap 上限，因为 Linux cgroup v1/v2 的 memory 子系统中，--memory-swap 并非独立控制 swap，而是「内存 + swap 总量」的硬上限；且 swap 本身会严重损害微服务低延迟、高吞吐的特性。真正可控、可预期的做法是：用软性机制引导内核早回收，保留极小缓冲空间防突发，而非靠 swap 上限“兜底”。
swap 不是缓存，是性能毒药
对 Spring Boot、gRPC、Node.js 等响应敏感型微服务，swap 触发意味着物理内存已严重不足，内核开始换出匿名页——这会导致：
- GC 停顿飙升（尤其 Java，G1/CMS 频繁触发 Full GC）
- HTTP 请求 P99 延迟跳变（毫秒级变秒级）
- 线程阻塞在
D状态（uninterruptible sleep），docker stats显示 MEM% 高但实际可用内存极低
正确设置：用 memory.reservation + 有限 swap 缓冲
替代直接设 --memory-swap=2g 这类刚性上限，应组合使用：
-
--memory=2g：物理内存硬上限（OOM Kill 触发点） -
--memory-reservation=1.6g：软性预留，内核在使用超此值时主动回收 page cache、触发 LRU 淘汰，避免突刺式 swap -
--memory-swap=2.2g：即允许最多 200MB swap，仅为应对短时流量尖峰或 GC 瞬间抖动，不是常态资源
这样配置后，/sys/fs/cgroup/memory/xxx/memory.stat 中的 pgmajfault（主缺页）和 pgpgout（换出页数）会显著下降，under_oom 保持为 0。
禁用 swap 的风险比你想象的大
设 --memory-swap=2g（等于 --memory）等价于禁用 swap。看似“干净”，实则剥夺了内核最后的弹性缓冲。当突发请求导致瞬时内存分配激增（如批量反序列化、临时对象爆发），OOM Killer 会立即杀死主进程——没有预警、不可控、无日志上下文。生产环境应始终保留小比例 swap（建议 ≤10% of --memory）作为安全气囊。
验证是否生效：看 cgroup 原生指标，不是 docker stats
运行中检查真实行为：
-
cat /sys/fs/cgroup/memory/docker/<container-id>/memory.oom_control</container-id>→under_oom 0表示未陷入 OOM -
cat /sys/fs/cgroup/memory/docker/<container-id>/memory.stat | grep -E "(pgpgin|pgpgout|pgmajfault)"</container-id>→pgpgout持续增长说明 swap 正被频繁使用，需调低--memory或优化应用内存泄漏 -
cat /sys/fs/cgroup/memory/docker/<container-id>/memory.swappiness</container-id>→ 默认为 60，高性能场景建议 echo 1 到该文件（仅影响内核换出倾向，不影响上限）
