容器资源限制需贴合真实负载：cpu用--cpu-shares（权重）与--cpus（硬限）协同，内存用-m设硬上限并禁用swap，java等需预留堆外空间，初始参考1核:2gb，再依监控数据校准。
容器资源限制不是“设了就完事”，关键在于让限制值贴合真实负载，既不让应用因饥饿而卡顿，也不让资源空转造成浪费。
CPU限制：用好“份额”和“硬限”两个层次
CPU资源可压缩，适合用相对权重配合硬性上限来管理：
- --cpu-shares 设定调度优先级（默认1024），多个容器争抢时按比例分配时间；适合同节点部署的非关键服务间协调
-
--cpus 是硬性上限（如
--cpus 1.2），防止突发计算压垮整机；对Web API、批处理等有明确峰值的服务更实用 - 若应用对延迟敏感（如实时音视频转码），可搭配 --cpuset-cpus 绑定特定物理核，减少上下文切换抖动
内存限制：宁紧勿松，但要留出缓冲余量
内存不可压缩，超限直接触发OOM Killer，必须谨慎设置：
- 用 -m / --memory 设硬上限（如
-m 1g），同时配 --memory-swap=1g 禁用swap，避免延迟不可控 - 内存请求（request）建议比应用常驻用量高20%~30%，覆盖JVM堆外内存、缓存预热、临时对象等隐性开销
- 对Java、Node.js等带运行时的程序，需额外关注GC行为——堆大小设为内存限制的60%~75%，留足元空间和线程栈空间
配比与验证：从监控中反推合理值
没有放之四海皆准的数值，得靠真实数据校准：
- 上线前做压力测试，用
docker stats或 Prometheus 抓取CPU使用率、内存RSS、page faults等指标 - 观察高峰期内存是否持续逼近限制值，若长期在90%以上波动，说明限制偏紧；若常年低于40%，可能浪费资源
- 推荐初始配比参考：通用服务按 1核CPU : 2GB内存 起步，计算密集型（如AI推理）可调至1:1，内存密集型（如Redis）可到1:4甚至更高
环境适配：别忽略编排层的叠加约束
单容器限制只是基础，Kubernetes等平台还有上层策略影响最终效果：
- Docker Compose 中的
reservations保证启动资源，limits控制峰值，两者配合避免冷启动失败 - K8s中 LimitRange 可为整个命名空间设默认限制，防止开发漏配；ResourceQuota 则防止单个团队占满集群
- 注意cgroup v2兼容性——较新Linux发行版默认启用，部分老镜像可能因/proc/sys读写异常报错，需检查基础镜像适配情况
