Nginx生产环境worker_processes配置核心是让每个worker稳定绑定一个物理CPU核，需与worker_cpu_affinity、worker_rlimit_nofile、use epoll协同生效；优先用auto但须结合部署环境调整。
Linux Nginx 生产环境的 worker_processes 配置，核心不是“设多少”，而是“让每个 worker 稳定跑在一个物理 CPU 核上”。只改这一项几乎没效果，必须和 CPU 绑定、文件描述符、事件模型协同生效。
优先用 worker_processes auto;，但要懂它在做什么
这是 Nginx 1.3.8+ 的推荐写法，会自动读取系统逻辑 CPU 数（比如 8c16t 就设为 16）。但它只是起点——在容器、K8s 或开启超线程的机器上，这个值容易偏高或偏低：
- 物理服务器：auto 可用，配合
worker_cpu_affinity auto;（Nginx ≥ 1.9.10）能跳过超线程对称核，优先绑定物理核 - Kubernetes Pod：必须与
resources.limits.cpu: "4"严格一致，写worker_processes 4;；若用 auto，需确认基础镜像支持 cgroups v2，否则可能误读宿主机 64 核 - Docker 容器：限制了 2 vCPU，就写
worker_processes 2;；不要依赖 auto 在旧版 cgroups v1 下的表现 - OpenVZ 或老旧虚拟化：
nproc常返回 1，auto 会退化成单进程，必须手动覆盖
物理核数才是基准，别被超线程带偏
Nginx worker 是重量级进程，共享 L1/L2 缓存。绑在同一物理核的两个逻辑核（超线程）上，反而互相干扰、降低缓存命中率。查真实物理核心数：
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
-
lscpu | grep -E "Core\(s\) per socket|Socket\(s\)"→ 相乘得物理核总数（如 2 sockets × 12 cores = 24） -
nproc或lscpu | grep "CPU(s):"只看逻辑核数，仅作参考 - 常见误区：32c64t 机器不建议直接设 64；8c16t 机器起点应是 8，不是 16
必须配套生效的三个关键参数
光调 worker_processes 不解决任何实际问题。以下三项必须同步配置，缺一不可：
-
CPU 绑定：加
worker_cpu_affinity auto;（推荐），或手动写掩码（如四核：0001 0010 0100 1000）。验证命令：ps -eo pid,psr,comm | grep nginx，看每个 worker 的 PSR 列是否稳定落在不同 CPU 编号上 -
文件描述符扩容：系统级
ulimit -n 65536（临时），永久写入/etc/security/limits.conf：nginx soft nofile 65536nginx hard nofile 65536
再在 main 块加worker_rlimit_nofile 65536; -
连接与事件模型：events 块中必须有
use epoll;（Linux 必显式启用），并设worker_connections 4096;（建议范围 2048–8192，视内存和业务调整）
按业务类型微调，不是所有场景都要填满物理核
物理核数只是起点，最终值取决于负载特征：
- I/O 密集型（静态文件、高命中反向代理、CDN）：1～4 个 worker 往往足够，再多收益递减，还可能增加上下文切换
-
CPU 密集型（全站 HTTPS、OpenResty + Lua 计算、实时压缩）：可设为物理核数，但要监控
vmstat 1中的cs（上下文切换）是否异常升高 - 混合或长连接场景（WebSocket、gRPC、上游响应慢）：建议设为物理核数的 1/2～3/4（如 16 核设 8～12）
-
资源共用服务器（Nginx 和数据库同机）：预留 1～2 核，用
worker_processes $(nproc --all) - 2;（需在启动脚本中执行）
