Docker 容器共享宿主机内核，隔离资源主要依靠 Linux cgroups 等机制。没有设置资源限制的容器可能竞争宿主资源，尤其在多业务共用节点时会放大故障影响。
内存上限与交换空间必须一起理解
docker run --memory=512m 会限制容器可使用的内存；--memory-swap 表示容器内存与交换的合计上限，在不同配置下含义不同。设得太小会触发 OOM 杀进程，但关闭 OOM 保护又可能危及宿主机。容器里的 free 并不总是直接表示该容器真实可使用的内存限制。
CPU quota 不是独占 vCPU
--cpus=1.5 表示在调度周期内可使用的 CPU 计算时间上限，不意味着固定预留了一颗半核心；--cpu-shares 体现资源争用时的相对权重。需要更强的 NUMA 或 CPU 亲和性，可另外考虑 cpuset，但先要确认宿主机拓扑和影响范围。
容器性能还受 I/O 与网络影响
只设置 CPU、内存无法阻止错误日志写满磁盘，或容器耗尽文件描述符。建议把磁盘配额、重启策略、健康检查、网络白名单和指标采集一起纳入部署审查，避免将生产实例直接暴露 Docker Socket。
实施前需要记录的三类证据
| 检查维度 | 应记录的内容 | 操作与验收方法 |
|---|---|---|
| 硬限制 | –memory、–cpus、cgroup 版本 | 容器内外核实实际限制 |
| 异常行为 | OOMKilled、退出代码、服务响应 | 受控压力测试并看事件日志 |
| 回退能力 | 资源配置、并发上限与扩容阈值 | 回滚单次调整并观察变化 |
容器进程启动到监控及容量调整：工作流程图
以下流程是落地执行顺序，建议为每一步保留配置快照、操作人和校验结果；在生产环境修改之前先准备恢复路径。
- 容器进程启动：明确当前环境与业务目标，列出系统版本、权限、地域和预期负载。
- cgroups资源约束：根据上一阶段信息选择可回退的配置，避免同时修改多个相互影响的变量。
- 宿主机调度与OOM：以受控测试或对照环境验证配置，遇到异常优先查看日志和监控。
- 监控及容量调整：记录结果和剩余限制，把复测触发条件纳入日常巡检。
怎样判断方案有效，以及不适用的情况
验收依据：以受控容器观察 `docker stats`、CPU throttle、OOMKilled 事件与业务 p95 延迟，逐级施加负载确认限制生效。
使用限制：资源限制不等于容器可抵御恶意突破；不要让不可信工作负载默认获得特权或宿主机挂载权限。
如果观察结果不稳定，先保持业务场景、测试位置与时间段可比，再判断是资源瓶颈、服务边界还是配置错误。缺少可复现的数据时，不应把单次结果外推成稳定收益。
官方资料与进一步阅读
- Docker：CPU/内存资源限制、OOM 行为：以产品/项目的现行官方说明为配置与版本核查依据。
- NIST：网络安全治理与风险管理框架：以产品/项目的现行官方说明为配置与版本核查依据。
延伸阅读：CentOS 安装 RabbitMQ 的正确方法：系统支持、卸载与迁移；云服务效率优化：先度量资源浪费，再调配置。
