必须显式设置资源限制，否则容器会吃光宿主机资源；docker run 用 --cpus 和 -m/--memory 控制 CPU 与内存，--memory-swap 需 ≥ --memory，--oom-kill-disable=true 仅限调试；docker-compose 中需写在 deploy.resources.limits 下才生效。
必须显式设置资源限制，否则容器会吃光宿主机资源——这不是建议，是生产环境的铁律。
docker run 里怎么加 CPU 和内存限制
直接在 docker run 命令里加参数最简单，也最可靠。不依赖 Compose 或 Swarm 模式，所有 Docker 版本都支持。
-
--cpus=1.2：硬性限制最多用 1.2 个逻辑 CPU 核心（基于 CFS 配额），比--cpu-shares更可控；注意小数点后一位是有效精度，--cpus=1.25会被截断为 1.2 -
-m 512M或--memory=512m：强制内存上限，单位大小写敏感，512M合法，512m也合法，但512MB会报错 -
--memory-swap=1G：必须 ≥--memory值，设为-1表示不限 swap，设为和--memory相同值（如--memory=512M --memory-swap=512M）则完全禁用 swap - 别漏掉
--oom-kill-disable=true：仅在极少数调试场景下用，生产环境禁用——它会让 OOM 时内核杀容器内进程而非整个容器，反而更难排查
docker-compose.yml 里资源限制不生效？检查 deploy 层级
很多人把 cpus 或 mem_limit 写在 service 根层级，结果启动没报错但限制无效——因为这些字段只在 deploy.resources.limits 下才被识别，且仅在 Swarm 模式或 Compose v3+ 的某些运行器中生效。
- 正确写法必须嵌套两层：
deploy → resources → limits，例如：cpus: '0.5'（字符串形式，带单引号）和memory: 512M -
cpuset-cpus: "0-1"这类绑定 CPU 核心的参数，不在deploy下，而在 service 根层级，和image、ports并列 - 本地开发用
docker-compose up时，默认不启用deploy配置；要强制启用需加--compatibility参数，或改用docker stack deploy - 如果只是单机运行又想用 Compose 文件做资源控制，不如直接用
docker run参数，避免配置歧义
为什么设置了 --cpus 却看到 top 里 CPU 使用率超 100%
这是常见误解：--cpus=0.5 不代表“最多显示 50% CPU 使用率”，而是指“每 100ms 最多运行 50ms”。top 显示的是单核利用率百分比，若容器绑定了 2 个核（--cpuset-cpus="0,1"）又限了 --cpus=0.5，它可能在核 0 上跑满 100%，同时核 1 完全空闲——此时 top 总体仍可能显示 100%，但实际调度受控。
- 验证真实配额是否生效，用
docker stats <container>看CPUs列（显示已分配上限）和CPU %列（当前使用占比） - 用
cat /sys/fs/cgroup/cpu/docker/<container-id>/cpu.cfs_quota_us和cpu.cfs_period_us手动确认内核 cgroup 设置是否写入 - 注意：容器内看到的
/proc/cpuinfo仍是宿主机全部 CPU 信息，不能用来判断限制是否生效
内存限制踩坑：--memory 和 --memory-swap 的组合逻辑
这两个参数共同决定容器能用多少“物理内存 + swap”，但组合方式容易搞混：
-
-m 200M --memory-swap=300M→ 最多用 200M 物理内存 + 100M swap -
-m 200M（未设 swap）→ 默认--memory-swap=400M，即 200M 物理 + 200M swap -
-m 200M --memory-swap=-1→ 200M 物理内存 + 无上限 swap（危险！可能拖垮宿主机） - 压测验证时用
progrium/stress镜像：--vm-bytes 299M在上面第一种配置下能跑，--vm-bytes 301M会直接被 OOM Killer 杀掉并退出
最易忽略的一点：Linux 内核对 cgroup v1 的 memory 子系统有延迟回收机制，docker stats 显示的内存使用量可能比实际 RSS 高出几十 MB，别一看到“超限”就 panic，先看 OOM 日志：dmesg -T | grep -i "killed process"。
