默认状态说明
容器默认没有资源上限：不写任何限制时，它可以占用宿主机的全部 CPU 与内存。于是单个服务的内存泄漏或死循环就足以把整台机器拖垮，连带同宿主上的其他容器一起受影响。常规做法是按服务画像设置基线，给出内存硬限与 CPU 配额，必要时再加进程数上限，然后按压测与监控结果微调。
基本信息
| 默认状态 | CPU 无上限、内存无上限 |
|---|---|
| 主要风险 | 单容器故障放大为整机故障 |
| 基线组合 | --memory / --cpus / --pids-limit |
| 查看方式 | docker inspect 的 HostConfig 对应字段 |
| 生效时机 | 创建容器时写入，改动用 docker update |
典型使用场景
- 上线前给每个服务定内存与 CPU 上限，避免互相抢占
- 多团队共用宿主时做基本隔离
- 排查偶发整机卡死：先确认是否缺少限制
- 容器被 OOM 杀掉后回看当时的限制值
- 容量规划：按容器实际用量反推宿主规格
检查与设置基线
检查与设置基线
# 查看运行中容器是否设置了限制
docker inspect -f '{{.Name}} mem={{.HostConfig.Memory}} cpu={{.HostConfig.NanoCpus}} pids={{.HostConfig.PidsLimit}}' $(docker ps -q)
# 创建时给出基线限制
docker run -d --name api --memory=512m --cpus=1.5 --pids-limit=256 app/api:1.4.2
# 观察实际用量后再微调
docker stats --no-stream --format '{{.Name}} {{.MemUsage}} {{.CPUPerc}}'参数含义对照
| 参数 | 含义 | 备注 |
|---|---|---|
| --memory | 内存硬上限 | 超过会被内核杀掉，退出码常见 137 |
| --cpus | CPU 配额 | 可为小数，1.5 表示最多 1.5 个核 |
| --pids-limit | 进程与线程数上限 | 防御 fork 炸弹，注意语言运行时线程数 |
| --memory-swap | 交换区上限 | 需与 --memory 一起理解，默认行为与版本相关 |
限制从粗到细逐层加：先给内存与 CPU 上限，再按压测与线上监控微调，避免一次定得过死导致频繁被限流或被杀。
docker update 可以在不重建容器的情况下调整部分资源限制，但并非所有字段都支持，改完用 inspect 确认实际生效的值。
限制值的单位要写清：--memory=512m 是 512MiB，写成 512 会被当成字节量，与预期相差极大。