Nginx 的 worker_processes auto 在容器中默认读取宿主机逻辑核数而非 cgroups 限制的 vCPU 数，易导致进程过载或资源浪费；应通过 entrypoint 脚本解析 /sys/fs/cgroup/cpu.max 或 cpuset.effective_cpus 动态计算并注入准确值，再验证 nginx -T 与 ps 输出是否一致。
在容器化环境中，Nginx 的 worker_processes auto 默认行为可能无法准确识别实际可用的 CPU 资源——它读取的是宿主机的逻辑核数，而非容器通过 cgroups 限制后的可用核数。这会导致 worker 过多（资源争抢、上下文切换开销）或过少（无法压满资源），影响吞吐与延迟。解决的关键是让 Master 进程在启动时真正感知容器的 CPU 配额（如 cpu.cfs_quota_us / cpu.cfs_period_us 或 cpuset.cpus），并据此设置合理的 worker 数量。
理解 auto 模式的真实行为
Nginx 1.19.2+ 的 auto 默认调用 sysconf(_SC_NPROCESSORS_ONLN)，该系统调用返回的是内核当前在线的逻辑 CPU 数，**不感知 cgroups 限制**。即使容器只被分配了 2 个 CPU 核，auto 在 32 核宿主机上仍会启动 32 个 worker。这不是 bug，而是设计使然——Nginx 本身不解析 cgroups 文件系统。
手动适配：启动前计算并覆盖配置
最可靠的方式是在容器启动时，由入口脚本（entrypoint）动态生成 worker_processes 值，并注入 nginx.conf。常用策略有：
-
基于 cpuset.cpus（推荐）：读取
/sys/fs/cgroup/cpuset/cpuset.effective_cpus（v2）或/sys/fs/cgroup/cpuset/cpuset.cpus（v1），解析出 CPU 列表长度（如0-1,4→ 3 个 CPU），设为 worker 数； -
基于 cpu quota（适合弹性限频场景）：读取
cpu.cfs_quota_us和cpu.cfs_period_us，计算quota / period向上取整（如 100000/100000=1，250000/100000=2.5→3），作为理论最大并发 worker； -
保守兜底：若 cgroups 文件不可读（如特权不足），回落到
min(容器内存 GiB × 2, 宿主机逻辑核数)，避免过度分配。
使用 nginx -g 动态传参（无需改配置文件）
在 docker run 或 Kubernetes initContainer 中，可直接用命令行覆盖：
nginx -g "worker_processes $(get_worker_count); error_log /dev/stderr info;"
其中 get_worker_count 是你封装好的 shell 函数，例如：
get_worker_count() {
if [[ -f /sys/fs/cgroup/cpuset.cpus ]]; then
awk '{gsub(/[^0-9,-]/,""); gsub(/,$/,""); n=split($0,a,","); s=0; for(i=1;i<=n;i++) {if(index(a[i],"-")){split(a[i],r,"-");s+=r[2]-r[1]+1}else{s++}}; print s}' /sys/fs/cgroup/cpuset.cpus
elif [[ -f /sys/fs/cgroup/cpu.max ]]; then
# cgroup v2: cpu.max = "100000 100000" → 1 CPU
awk '{print int($1/$2)}' /sys/fs/cgroup/cpu.max
else
nproc
fi | head -c10
}验证是否生效
容器运行后，检查：
-
ps aux | grep nginx | grep master—— 确认 master 进程参数含预期 worker 数； -
nginx -T 2>/dev/null | grep worker_processes—— 查看最终加载的配置值； -
cat /proc/$(pidof nginx)/status | grep -i "cap.*eff"—— 确保进程有权限读 cgroups（通常需要cap_sys_admin或挂载 cgroup fs）。
不复杂但容易忽略。
