容器资源配额限制防止进程耗尽内存CPU资源配置
为什么需要限制容器资源
当多个容器运行在同一台服务器上时，任何一个容器内的进程都可能因为 fork bomb、内存泄漏或流量突增而耗尽整个宿主的CPU和内存资源。
不设置配额的结果就是：一个容器垮掉，连带其他容器甚至系统服务一起崩溃。
容器资源配额限制是防止这类连锁故障的基本手段。
前置环境准备
在开始限制资源之前，请确保你已经满足以下条件：
- 安装Docker（版本 >= 1.13，推荐 20+）。命令行执行
docker --version确认。 - 拥有sudo或root权限，或者在docker组中（非root用户需要
sudo）。 - 一台Linux虚拟机或物理机（Windows/macOS使用Docker Desktop时限制逻辑相同，但部分参数可能存在差异）。
- 了解基础Docker命令：
docker run、docker ps、docker stats。
如果你还没有Docker环境，可以参考官方文档或本站《Docker安装与配置》教程快速搭建。
核心操作：用配额参数启动容器
Docker启动容器时，通过 --memory 和 --cpus 两个核心参数来限制资源。
下面是两个实战场景。
场景一：限制容器可用内存
假设一个Web应用可能因为内存泄漏导致OOM（Out Of Memory），我们将其限制在 256 MB 以内：
docker run -d --name web-test --memory 256m nginx:alpine参数说明：
--memory 256m：硬限制，最大允许使用256MB，超过时容器内的进程将被OOM Killer杀掉。- 你可以使用
b（字节）、k（千字节）、m（兆字节）、g（吉字节）等后缀。
如果想同时限制交换（swap）占用，可以追加 --memory-swap 512m（表示允许的内存+swap总共512MB）。
但通常生产环境建议关闭swap，提升性能一致性。
场景二：限制容器可用CPU核数
限制CPU并非锁定物理核心，而是控制CPU时间片的相对权重或上限。
Docker 1.13之后推荐使用 --cpus 参数（基于CFS配额）。
docker run -d --name cpu-test --cpus 1.5 nginx:alpine这个容器最多能使用 1.5个CPU核心（即150%的CPU时间）。
注意：--cpus 不直接绑定物理核，而是调度总时间片。
如果想更细粒度控制，可以配合 --cpu-shares（相对权重）或 --cpuset-cpus（绑定指定核），但对于零基础用户，--cpus 已经足够。
同时限制内存和CPU
最常见的做法是同时指定内存和CPU限制：
docker run -d \
--name my-app \
--memory 512m \
--cpus 2 \
nginx:alpine这样容器最大使用512MB内存、最多占用2个CPU核心。
验证资源限制是否生效
启动容器后，不要只看日志，要主动验证配额是否落实。
方法一：使用 docker inspect
docker inspect my-app | grep -E "(Memory|NanoCpus)"输出示例：
"Memory": 536870912,
"NanoCpus": 2000000000,说明限制已经写入容器配置。
方法二：使用 docker stats 实时监控
docker stats my-app你会看到实时的CPU%、MEM USAGE / LIMIT。
如果手动在容器内运行压力工具（如 stress），当内存或CPU超过限制时，OOM或CPU会被节流（throttled）。
方法三：主动触发超限测试（选做）
仅在测试环境验证，不要在生产环境执行。
安装 stress 工具：
docker exec my-app apk add stress启动内存压力（目标400MB，而限制512MB，留有余量）：
docker exec my-app stress --vm 1 --vm-bytes 400M --timeout 10s观察 docker stats 中内存使用不会超过512MB。
如果试图超过，进程会被杀掉。
避坑指南
- Swap未关闭导致内存限制失效：若宿主机启用了swap，Docker默认允许容器使用swap，实际可用内存 =
--memory+--memory-swap的一部分。建议在docker run中加上--memory-swap 0（表示禁用swap）或显式设置相同值。 --cpus与--cpu-quota、--cpu-period的关系：前者是后两者的简便计算。不要同时混用，否则行为可能不符合预期。- 不设置限制时默认行为：不设
--memory则容器可任意使用宿主机内存，直到触发系统OOM。不设--cpus则默认无上限，可抢占所有CPU时间。 - 限制后容器内应用优化：并不是给够资源就完事，应用本身的连接池、线程数也要适配限制，防止内存和CPU先被应用框架吃掉。
高频问题解答
Q1：限制CPU后容器内应用还是跑满了CPU，怎么办？
检查 --cpus 参数是否正确（Docker 1.13+），然后用 docker update --cpus 0.5 随时调整。如果应用是多线程的，CPU限制会控制总时间片，应用内部可感知到的CPU核心数可能是有限的（通过 --cpuset-cpus 可绑定物理核）。
Q2：容器被OOM Kill后如何自动重启？
加上 --restart unless-stopped 即可：
docker run -d --name safe-app --memory 256m --restart unless-stopped nginx:alpineOOM后Docker自动拉起容器。
Q3：已经运行的容器如何修改配额？
使用 docker update 命令：
docker update --memory 512m --cpus 2 my-existing-container注意：docker update 不支持所有参数（如 --memory-swap），最好优先在 docker run 时设定好。
Q4：限制资源会影响容器内性能吗？
合理限制只会在超过配额时产生节流，不会降低正常负载下的性能。设置太小的配额可能导致应用频繁被杀或请求响应变慢，需要根据实际压力测试调整。
总结
容器资源配额是生产环境中必须落实的安全基线。
通过 --memory 和 --cpus 参数，你可以在启动容器时直接锁定资源上限，再配合 docker stats 和 docker inspect 验证效果。
关键要点：先测试再上线、注意swap影响、预留一点余量。
如果你的容器已经跑起来，用 docker update 也能动态调整。
后续还可以结合 docker-compose 在 YAML 中定义 deploy.resources，实现更复杂的资源编排。
如果你在配置过程中遇到异常，先回看避坑部分，或查看Docker官方文档。
坚持先限制再跑，才能让一台服务器承载更多稳定服务。
