应设 worker_processes auto 并启用 worker_cpu_affinity auto；物理核数即进程数，避免超线程，同步调高文件描述符限制至 ulimit -n ≥ 进程数×连接数×1.2。

worker_processes 不是填个大数字就能提速，关键在于让每个 worker 进程稳定对应一个可用的物理 CPU 核心，减少调度干扰和缓存失效。

优先用 auto，自动适配真实核数

直接写 worker_processes auto; 是最稳妥的做法。Nginx 1.3.8+ 会读取当前环境的物理核心数（不含超线程），比如 4 物理核就启 4 个进程。这比手动写死更可靠，尤其在虚拟机、Docker 或 Kubernetes 环境中——官方镜像和较新内核通常能正确识别 cgroups 限制。

• 物理服务器：auto 基本等于物理核心数
• Docker 容器：若只分配了 2 vCPU，auto 一般也能识别，但建议验证 nproc --all 输出
• Kubernetes Pod：如果设置了 resources.limits.cpu: "2"，需确认基础镜像支持 cgroups v2，否则可能误读宿主机核数

手动设置时盯准物理核心，避开超线程

必须手动指定时，以物理核心数为准。例如 8 核 16 线程的机器，应设为 worker_processes 8;，而不是 16。超线程对 Nginx 这类 I/O 密集型服务提升有限，反而容易加剧 L1/L2 缓存争用和上下文切换开销。

Nginx Config Linter

对 Nginx 配置文件进行语法检查、验证和安全、性能审计。

下载

• 查物理核心总数：nproc --all 或 lscpu | grep "Core(s) per socket" × Socket 数
• 混合部署（如同时跑 MySQL）：预留 1–2 核，可设为 worker_processes $(nproc --all)-2;
• 避免设为 1（除非调试）或超过物理核数的 1.5 倍

必须绑定 CPU 亲和性，固定运行位置

只调进程数不绑定核心，等于白调。系统调度器可能把多个 worker 挤在同一核上，或频繁迁移，导致缓存失效、延迟不稳。启用 worker_cpu_affinity 后，每个 worker 固定运行在指定核心，L1/L2 缓存命中率明显提升。

• 通用写法：worker_cpu_affinity auto;（Nginx 1.9.10+ 支持，自动错开超线程对）
• 双核示例：worker_cpu_affinity 01 10;
• NUMA 架构（如双路服务器）：先用 numactl --hardware 查节点布局，再按节点均分 worker 并分别绑定，避免跨节点内存访问

同步调高文件描述符限制，防止“有核无粮”

worker_processes 翻倍后，若系统级文件描述符没跟上，很快就会报 Too many open files 错误，QPS 卡死。

• 系统级：在 /etc/security/limits.conf 中设 * soft nofile 65535 和 * hard nofile 65535，并确保 systemd 加载（如加 LimitNOFILE=65535 到 service 文件）
• Nginx 配置：在 main 块加 worker_rlimit_nofile 65535;
• 启动前检查：ulimit -n 应 ≥ worker_processes × worker_connections 的 1.2 倍

不复杂但容易忽略