Linux如何配置Docker资源限制_Linux Docker资源限制配置技巧-LINUX-PHP中文网

必须显式设置资源限制，否则容器会吃光宿主机资源；docker run 用 --cpus 和 -m/--memory 控制 cpu 与内存，--memory-swap 需 ≥ --memory，--oom-kill-disable=true 仅限调试；docker-compose 中需写在 deploy.resources.limits 下才生效。

linux如何配置docker资源限制_linux docker资源限制配置技巧

必须显式设置资源限制，否则容器会吃光宿主机资源——这不是建议，是生产环境的铁律。

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></container> 看 CPUs 列（显示已分配上限）和 CPU % 列（当前使用占比）
用 cat /sys/fs/cgroup/cpu/docker/<container-id>/cpu.cfs_quota_us</container-id> 和 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"。