使用CPU和内存限制优化Docker容器性能

Docker容器不会自动像固定资源的小型虚拟机那样运行。除非你告诉Docker，否则容器可以像其他进程一样竞争主机的CPU和内存。这在笔记本电脑上很方便，但在共享服务器上则存在风险。

CPU和内存限制并不是神奇的性能提升器。限制过低会使应用程序变慢或不稳定。限制过高则无法保护主机。目标是给每个容器足够的空间处理正常和峰值工作，同时防止一个故障进程拖垮机器上的其他所有进程。

为什么限制很重要

常见的故障模式很熟悉：一个容器启动失控任务，内存攀升，主机开始交换，无关服务变慢。或者一个CPU密集型批处理任务使用所有核心，旁边的API容器开始错过延迟目标。

限制有助于解决三个实际问题：

• 它们保护主机免受单个容器使用所有内存的影响。
• 它们使性能测试更真实，因为容器在类似生产环境的约束下运行。
• 它们迫使你注意应用程序何时需要扩展或调优，而不是默默借用邻居的资源。

不要从随机数字开始。在负载下运行服务，观察实际使用情况，并设置带有余量的限制。一个小型后台工作进程和一个JVM服务需要非常不同的处理方式。

CPU控制

Docker提供了几个CPU控制选项。日常最有用的是--cpus。

将容器限制为大约一个半CPU：

docker run -d --name api --cpus="1.5" nginx

这比手动设置CFS配额和周期更容易理解。在底层，Docker使用Linux CPU调度控制。

--cpu-shares则不同。它是CPU竞争时的相对权重，而不是硬性限制：

docker run -d --name important-api --cpu-shares 2048 nginx
docker run -d --name batch-worker --cpu-shares 512 worker-image

当主机CPU空闲时，两个容器都可以使用更多。当它们竞争时，第一个容器有更高的调度权重。这对于优先级设置很有用，但它不会阻止容器使用空闲CPU。

如果你需要精确的CFS设置，--cpu-period和--cpu-quota仍然可用：

docker run -d --name limited-api \
  --cpu-period 100000 \
  --cpu-quota 50000 \
  nginx

这给容器在每个100,000微秒周期内50,000微秒的CPU时间，大约相当于半个CPU。对于大多数团队来说，--cpus="0.5"更清晰地传达了相同的意图。

内存控制

内存限制比CPU限制更危险，因为超出限制可能会杀死进程。要谨慎设置并测试峰值行为。

基本选项是--memory：

docker run -d --name web --memory 512m nginx

如果容器超出限制，内核可能会杀死容器中的一个进程。在Docker输出中，你通常会看到OOM杀死：

docker inspect web --format '{{.State.OOMKilled}}'

交换行为容易误解。当设置--memory时，--memory-swap是总内存加交换配额，而不是单独的交换配额。

这允许256 MB RAM和最多256 MB交换，总共512 MB：

docker run -d --name worker --memory 256m --memory-swap 512m alpine

将--memory-swap设置为与--memory相等，可以在支持交换记账的系统上禁用该容器的额外交换：

docker run -d --name no-extra-swap --memory 256m --memory-swap 256m alpine

将--memory-swap设置为-1允许无限交换，直到主机的可用交换。这可能会保持进程存活，但可能导致延迟极差。

前后监控

在服务处于实际负载下时使用docker stats：

docker stats
docker stats web worker

观察CPU %、MEM USAGE / LIMIT、BLOCK I/O和PIDS。一个服务持续处于内存限制的100%并不是“高效”；它离被杀死只差一个流量峰值。一个持续被节流的CPU密集型服务可能显示可接受的平均CPU，但用户会看到慢请求。

快速一次性查看：

docker stats --no-stream

对于OOM和重启线索：

docker ps -a
docker inspect <container> --format 'OOM={{.State.OOMKilled}} Exit={{.State.ExitCode}}'
docker logs --tail 100 <container>

对于持续监控，将容器指标导出到Prometheus、Grafana、云监控服务或你已有的平台。docker stats是故障排查工具，不是长期告警系统。

合理的调优工作流程

在测试环境中从没有严格限制开始，捕获空闲、正常和峰值使用情况。然后设置内存高于观察到的峰值，并留有足够的余量用于垃圾回收、缓存增长、TLS握手和短突发。对于CPU，决定是需要硬性限制还是仅相对优先级。

小型API示例：

docker run -d --name api \
  --cpus="2" \
  --memory 1g \
  --memory-swap 1g \
  -p 8080:80 \
  my-api:latest

这意味着API最多使用两个CPU、1 GB RAM，并且没有额外交换配额。这不是普遍正确的。这是一个经过测试接近该范围的服务的一个清晰起点。

对于Docker Compose，本地Docker引擎支持资源选项，例如：

services:
  api:
    image: my-api:latest
    mem_limit: 1g
    cpus: 2.0

Compose和Swarm/Kubernetes的资源设置并不相同，因此在假设字段在所有地方行为一致之前，请检查部署目标。

常见错误

最常见错误是设置内存过低。应用程序启动，通过冒烟测试，然后在请求模式分配超过测试覆盖的内存时崩溃。

另一个错误是使用CPU限制来隐藏低效代码。如果服务因为每个请求执行昂贵工作而缓慢，较低的CPU限制会使症状更明显。它不会修复代码路径。

忽略语言运行时也会造成问题。JVM、Node.js、Go、Python和Ruby应用对内存压力的反应不同。一些运行时需要显式堆设置，以便其内部内存假设与容器限制匹配。

最后，不要只调优一个容器。主机仍然需要CPU和内存给内核、Docker、日志记录、监控代理和任何边车进程。留出空间。

好的限制使故障更小，性能更可预测。它们应来自测量，而不是猜测。