优化Nginx容器资源需双层协同：容器层设准CPU/内存硬限并选轻量镜像，Nginx层按限制调worker_processes、worker_connections等参数，非root运行、限客户端行为、关冗余模块，并通过docker stats和stub_status验证。
优化 Nginx 在容器环境下的资源限制，关键在于“双层协同”：既要让容器运行时（Docker/K8s）设好硬边界，又要让 Nginx 自身配置主动适配这些边界。只设 limits 不等于可控，不调参数反而容易触发 OOM 或上下文切换抖动。
容器层设准 CPU 和内存上限
这是第一道防线，防止 Nginx 吃光宿主机资源：
-
CPU 限制建议用 --cpus 或 K8s limits.cpu：例如设为
1.5，表示最多使用 1.5 个逻辑核；避免用--cpu-shares单独控制权重，它不设硬上限，竞争时仍可能超占 -
内存限制必须设 hard limit：如
--memory=384m或 K8s 中limits.memory: 384Mi；同时设requests.memory为 limit 的 70%~80%，比如256Mi，确保调度稳定、减少 cgroup throttling -
优先选轻量镜像：用
nginx:alpine-slim而非 full Debian 版，体积小 60%+，启动快、攻击面小、内存开销低
Nginx 层按容器规格动态调参
容器限制只是天花板，Nginx 必须知道自己能用多少资源，否则默认 worker_processes auto 可能创建过多进程：
-
worker_processes 不写 auto：设为与容器分配的 CPU 核心数一致（如限制 1.5 核 → 设
1；限制 2 核 → 可设2），避免进程争抢或闲置 -
worker_connections 按内存反推：每个连接约占 2KB 内存；若内存 limit 为 384Mi，预留 128Mi 给系统和日志，则可用约 256Mi → 约 131K 连接；搭配 2 个 worker，单 worker 设
8192更稳妥 -
启用自动调优脚本：在官方镜像中设置环境变量
NGINX_ENTRYPOINT_WORKER_PROCESSES_AUTOTUNE=1，脚本会自动检测 cgroup v1/v2 的 CPU 配额、CPU set 等，取最小值作为最终 worker 数
加固运行时，降低隐性开销
减少非必要消耗，让资源真正用于处理请求：
-
非 root 用户运行：构建时显式创建 nginx 组和用户（gid 101, uid 101），并在
Dockerfile中用USER nginx切换，既安全又减少权限检查开销 -
限制客户端行为：设
client_max_body_size 10m防大上传耗尽连接；client_header_timeout 15s和client_body_timeout 15s防慢速攻击 -
关闭不用模块：用
nginx -V查看编译参数，确认未启用冗余模块（如 perl、xslt）；生产环境推荐 slim/alpine 镜像，默认已精简
验证与监控不能少
调完不验证，等于没调：
-
实时看资源占用：用
docker stats <container></container>观察 CPU % 和 MEM USAGE / LIMIT，确保长期低于 limit 的 80% -
进容器查实际 worker 数：执行
docker exec -it <container> ps aux | grep nginx</container>，确认 master + worker 进程数是否符合预期 -
连入率指标要盯紧：配合
nginx stub_status或 Prometheus 抓取nginx_connections_active、nginx_connections_waiting，发现 waiting 长时间高，说明 worker_connections 或 ulimit 不足
