容器中 worker_processes 必须按实际分配的 vcpu 数显式设置，不可用 auto（会误读宿主机核数），如 limits.cpu: "2" 则设为 2；需配合 worker_rlimit_nofile、worker_connections 及 ulimit 等协同调优。

别直接写 worker_processes auto; —— 容器里它会读错核数，导致进程数远超实际可用 CPU，引发严重争抢和响应延迟。

容器环境必须按分配 vCPU 数显式设置

容器看到的 CPU 信息来自宿主机，但真实资源受 cgroups 限制。Kubernetes 中设 limits.cpu: 2，不代表给了 2 个物理核，而是每 100ms 最多用 200ms 的 CPU 时间片。Nginx 必须适配这个“有效并发能力”：

• 若容器限制为 --cpus=1.5 或 limits.cpu: 1.5，设 worker_processes 1（不支持小数，向下取整）
• 若限制为 --cpus=2 或 limits.cpu: "2"，设 worker_processes 2
• 云主机单核或边缘设备（如树莓派）上跑容器，一律设 1，避免上下文切换开销

优先使用支持自动探测的镜像

官方 nginx:alpine 和 nginx:slim 镜像自带 30-tune-worker-processes.sh 入口脚本，能读取 /sys/fs/cgroup/cpu/cpu.cfs_quota_us 等路径，动态计算可用 vCPU 数。前提是：

minimax-mcp-docker版（适配极空间）

MiniMax 图片理解 + 网络搜索 MCP 工具。适配 Docker 环境（极空间等），支持图片 OCR 识别、图像内容理解、网络搜索。API Key 安全存储在本地 credentials 文件，不暴露在代码中。

下载

• 启动时未硬编码 worker_processes（比如在 nginx.conf 里写死为 4）
• 没覆盖入口脚本逻辑（例如用 command: ["nginx", "-g", "daemon off;"] 绕过 entrypoint）
• 确保存在 cgroups v1 或 v2 的 CPU 限制文件（K8s 默认启用）

手动控制时推荐用环境变量注入

比改配置文件更灵活，尤其适合 CI/CD 或多环境部署：

• 在容器启动时传入：-e NGINX_WORKER_PROCESSES=2
• 配合模板机制（如 envsubst）替换 /etc/nginx/templates/nginx.conf.template 中的 ${NGINX_WORKER_PROCESSES}
• Dockerfile 中不要写 worker_processes 4；K8s YAML 中避免在 configMap 里固化该值

配套参数必须同步调优

只改 worker_processes 不够，还要匹配系统级与 Nginx 内部限制：

• worker_rlimit_nofile（主配置块）必须 ≥ worker_connections（events 块），常见设为 65535
• events { worker_connections 4096; use epoll; multi_accept on; } —— 连接数建议按 vCPU × 2048～4096 初步估算
• 检查容器内 ulimit -n，若低于 worker_rlimit_nofile，需在 /etc/security/limits.conf 或 Docker 启动参数中提升（如 --ulimit nofile=65535:65535）