worker_processes性能优化核心是匹配真实物理核心并绑定cpu亲和性，auto虽便捷但需结合nproc--all或lscpu查物理核数验证，容器/k8s中须按cgroups限制显式设置，并同步调高ulimit与worker_rlimit_nofile。
worker_processes 的性能优化核心在于“匹配真实计算资源，减少调度干扰”，不是简单调大数字，而是让每个工作进程稳定运行在专属物理核心上，同时打通系统级资源瓶颈。
用 auto 最稳妥，但得知道它到底读什么
直接写 worker_processes auto; 是当前最推荐的做法。Nginx 1.3.8+ 会自动读取可用 CPU 核心数，但在不同环境含义不同：
- 物理服务器：通常等于物理核心数（如 16 核 → 启 16 个进程）
- 容器或云主机：取决于 cgroups 限制，官方 nginx:alpine 镜像能识别 cpu quota，auto 依然有效
- Kubernetes Pod：若使用 cgroups v2 且镜像支持，auto 可靠；否则可能误读宿主机核数，建议配合 nproc --all 验证实际分配数
手动设置时盯准物理核心，别被超线程带偏
超线程（HT）对 Nginx 这类 I/O 密集型服务帮助有限，反而可能加剧缓存争用。判断依据是物理核心数，不是逻辑线程数：
- 查物理核心总数：nproc --all 或 lscpu | grep "Core(s) per socket" | awk '{sum += $4} END {print sum}'
- 例如 2 路 × 16 核 = 32 物理核，就设 worker_processes 32;，不建议设 64
- 混合部署（如同时跑 MySQL）可预留 1–2 核，设为 $(nproc --all)-2
必须绑定 CPU 亲和性，否则进程数调对也白搭
只设进程数不绑定核心，系统调度器仍可能把多个 worker 挤在同一核，或频繁迁移，导致缓存失效、延迟波动：
- Nginx 1.9.10+ 推荐写 worker_cpu_affinity auto; —— 自动错开超线程对，优先分配物理核
- 需要精细控制时（如 NUMA 架构），先用 numactl --hardware 查节点布局，再按节点分组绑定掩码
- 双核示例：worker_cpu_affinity 01 10;；四核示例：worker_cpu_affinity 0001 0010 0100 1000;
同步调高文件描述符，避免“有核无粮”
worker_processes × worker_connections 是理论最大连接数，但真正卡住的是系统级文件描述符限制：
- 确保 worker_rlimit_nofile ≥ 单个 worker 的 worker_connections（建议统一设为 65536）
- 系统 ulimit -n 至少设为 worker_processes × worker_connections × 1.2（如 8×4000=32000，ulimit 至少 38400）
- 永久生效需配置 /etc/security/limits.conf，并确认 nginx 启动用户适用
