容器资源限制怎么设置？Docker

为什么需要容器资源限制

刚接触容器时，很多人会发现一个容器跑起来后，可能会占光服务器的CPU或内存，导致其他服务变慢甚至崩掉。容器资源限制就是给每个容器单独划定CPU和内存的上限，让它不能超过你设定的值。
这样即使某个容器出问题，也不会拖垮整台机器。

今天这篇文章面向零基础的用户，我会用最常用的 Docker 来演示，所有命令都给出完整示例，你跟着敲就能看到效果。

准备工作：环境与工具

操作之前，请先确保服务器上安装了 Docker。
如果还没安装，可以参考官方文档或我之前写的安装教程（这里不再重复）。
检查 Docker 是否运行：

docker --version
docker info | grep -i version

推荐使用 20.10 以上版本，对资源限制支持更好。
如果版本太旧，部分参数可能不生效。

另外，你需要一台有足够内存和 CPU 的测试机器（比如 2 核 4G 的云服务器即可），因为我们要做压力测试。

核心操作：通过 docker run 限制 CPU 和内存

Docker 通过 --memory 和 --cpus 两个参数来控制容器的资源上限。--memory 设置最大可用内存，--cpus 设置最大可占用的 CPU 核心数（可以是小数）。

示例 1：限制内存为 256 MB

docker run -d --name test-mem --memory=256m nginx:alpine

用 docker stats test-mem 可以看到内存限制。

示例 2：限制 CPU 为 0.5 核

docker run -d --name test-cpu --cpus=0.5 nginx:alpine

示例 3：同时限制内存和 CPU

docker run -d --name test-both --memory=512m --cpus=1 nginx:alpine

这些参数在容器创建时生效，对已有容器不适用。
如果容器已运行，需要先删除再重建。

如果使用宝塔面板或 HestiaCP 等管理后台

在创建容器时，通常会有“高级设置”或“资源限制”区域，直接填写 CPU 和内存上限即可。
具体字段名可能不同，但原理一样。

避坑指南：常见错误与注意事项

1. 内存限制过小导致容器 OOM 被 Kill

• 表现：容器状态为 Exited (137)，日志显示 out of memory。
• 解决：逐步调大 --memory 值，或者根据容器内应用的实际内存需求来定。可用 docker stats 先查看未限制时的消耗。

1. CPU 限制过低导致服务响应慢

• 如果业务需要密集计算，CPU 限制不能太紧。建议先设为 1 或 2，观察后再微调。

1. --memory 不带单位会报错

• --memory 后面必须加单位，如 m（兆）、g（吉）。例如 --memory=1g 有效，但 --memory=1 会提示参数错误。

1. 同时设置 --memory-swap 可能引发混淆

• Docker 默认的 swap 限制等于内存限制的两倍；如果要严格控制，建议同时设置 --memory-swap，保持和 --memory 一致来禁用交换分区使用。

效果验证：如何确认限制生效

运行一个已限制的容器后，用下面两种方法确认。

查看容器实时状态

docker stats

会列出所有运行容器的 CPU%、内存使用/限制、网络 IO 等。
在“MEM USAGE / LIMIT”列可以看到你设定的限制值是否生效。

使用压力工具测试限制是否被遵守

这里用 stress 工具做演示。
先拉取一个带 stress 的镜像：

docker run -it --rm --memory=128m alpine sh -c "apk add stress && stress --vm 1 --vm-bytes 256m"

容器会试图申请 256MB 内存，但限制是 128MB，很快就会被 OOM Kill，退出代码 137。
这说明限制起了作用。

常见问题解答

Q：Docker 里的 --cpus 和 --cpu-quota 有什么区别？
A：--cpus 是简化版，Docker 内部会换算为 quota 和 period。新手直接用 --cpus 即可。

Q：我用的容器编排工具是 Kubernetes，资源限制怎么设置？
A：K8S 通过 YAML 里的 resources.limits.cpu 和 resources.limits.memory 定义。思路和 Docker 一致，但格式不同。我会在后续文章单独介绍。

Q：已运行的容器能加限制吗？
A：不能直接修改。必须先停掉容器，然后用新的参数重新创建。建议在启动前就规划好限制值。

如果你正在处理容器资源限制，建议先按本文步骤完整执行，再根据自己的环境做微调；
遇到异常时优先回看避坑和高频问题部分。
实际生产中，多观察几天资源使用曲线再确定最终限额，会更稳妥。