设 worker_processes auto 仅为起点，需同步确认物理核心数、绑定CPU亲和性、放开文件描述符限制、匹配事件模型与连接数，单改进程数几乎无效。
直接设 worker_processes auto; 是起点，但要真正压满多核性能，必须同步做四件事：确认物理核心数、绑定 CPU 亲和性、放开文件描述符限制、匹配事件模型与连接数。单改进程数几乎没效果。
先搞清你有多少个“真”物理核心
别看 nproc 或 lscpu | grep "CPU(s)" 显示的逻辑核数（比如 64），那是超线程（HT）翻倍后的数字。Nginx worker 是重量级进程，绑在同一物理核的两个逻辑核上反而争缓存、抖动大。
- 查真实物理核总数：
lscpu | grep -E "Core\(s\) per socket|Socket\(s\)"，相乘即得（如 2 sockets × 16 cores = 32 物理核） - 容器或 K8s 中，以
nproc --all输出为准——若 Pod limits.cpu: "4"，就按 4 核配，auto很可能误读宿主机 64 核，导致静默降级 - 双路或多路服务器还要留意 NUMA：跨节点访问远端内存会明显拖慢吞吐，不建议把所有 worker 均匀撒满总核数
必须绑定 CPU，否则调对也白搭
不绑定时，Linux 调度器可能把多个 worker 全挤到一个核上，频繁迁移导致 SSL 缓存失效、L2 预热归零、上下文切换飙升——实测 QPS 可跌 5%～15%。
linux-sysadmin
下载
Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...
- Nginx ≥ 1.9.10 推荐写：
worker_cpu_affinity auto;，它能自动跳过超线程对称核，优先绑定独立物理核 - 手动绑定示例（4 核物理机）：
worker_cpu_affinity 0001 0010 0100 1000;（位图从右往左对应 core 0–3） - 验证是否生效：
ps -eo pid,psr,comm | grep nginx，看每个 worker 的 PSR 列是否稳定落在不同 CPU 编号上
配套放开系统与 Nginx 的资源上限
worker_processes × worker_connections 才是理论并发上限，但三处卡点常让配置“形同虚设”：
- 系统级文件描述符：临时运行
ulimit -n 65536；永久生效需在/etc/security/limits.conf加两行：nginx soft nofile 65536nginx hard nofile 65536 - Nginx 内部声明：
worker_rlimit_nofile 65536;（写在 main 块） - 每个 worker 连接数：
events { worker_connections 4096; }，建议范围 2048–8192，视内存和业务类型调整 - 别漏掉事件模型：
use epoll;（Linux 必须显式启用）
按业务类型微调，不是死守物理核数
物理核数只是起点，最终值取决于实际负载特征：
- I/O 密集型（静态文件、高命中反向代理、缓存服务）：通常 1～4 个 worker 就够，再多收益递减，还可能抬高上下文切换
- CPU 密集型（全站 HTTPS、OpenResty + Lua 计算）：可设为物理核数，但务必监控
vmstat 1中的cs（上下文切换）是否异常升高 - 后端延迟高（如慢 API、gRPC、长轮询）：可略高于物理核数（如 ×1.2），但超过 1.5 倍通常得不偿失
- 混合部署（如 Nginx 和 MySQL 同机）：预留 1–2 核，设为
$(nproc --all) - 2
