nginx性能调优需科学设置worker_processes、worker_cpu_affinity、worker_rlimit_nofile和worker_connections四项参数，避免盲目设核数、不绑cpu、忽略系统限制及连接数不匹配等常见误区。
worker_processes 是 Nginx 性能调优的起点，但也是最容易“一步错、全盘拖”的关键参数。设不对，轻则单核 100%、其余核心空转；重则连接拒绝、延迟飙升、压测 QPS 不升反降。
误区一：盲目设为物理核心数或逻辑核数
很多人查到“32 物理核”就写 worker_processes 32，或看到“64 逻辑 CPU”就填 64——这在多数高并发场景下反而有害。超线程对 Nginx 这类 I/O 密集型服务提升有限，却会加剧缓存争用和上下文切换。实测中，设为 64 常导致惊群效应加重、SSL 握手延迟上升 8%～12%。
更稳妥的做法是：
- 优先使用 worker_processes auto;（Nginx 1.3.8+ 支持），它读取的是
nproc输出，准确反映容器或虚拟机实际可用逻辑核数 - 若需手动设置，以
nproc结果为准，而非lscpu | grep "CPU(s)"或/proc/cpuinfo（后者在云环境常返回宿主机核数） - 混合部署时（如与 MySQL 共存），主动减去预留核心：例如
nproc --all返回 16，可设为worker_processes 14;
误区二：只调进程数，不绑 CPU 亲和性
即使 worker_processes auto; 生效了，若没配 worker_cpu_affinity，Linux 调度器仍可能把多个 worker 挤在同一个物理核上，或频繁迁移——L1/L2 缓存反复失效，指令流水线被打断，性能损耗肉眼可见。
推荐做法：
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
- 直接写 worker_cpu_affinity auto;（Nginx 1.9.10+），自动避开超线程对，优先绑定物理核心
- NUMA 架构服务器需更精细控制：先用
numactl --hardware查节点分布，再按节点分组绑定，避免跨 NUMA 访存延迟 - 禁止多个 worker 绑定同一物理核，否则等于没绑；也别用十六进制掩码硬写（易出错），auto 已足够可靠
误区三：忽略系统级资源限制，导致“配置生效、效果归零”
worker_processes 和 worker_connections 决定了理论并发上限，但这个数字会被操作系统卡死。常见现象是：Nginx 日志报 accept() failed (24: Too many open files)，或压测时连接数刚过万就停滞。
必须同步完成三项检查：
- 在 nginx.conf main 块加：worker_rlimit_nofile 65535;
- 为 nginx 运行用户（如 www-data 或 nginx）在
/etc/security/limits.conf中设硬限制：www-data soft nofile 65535www-data hard nofile 65535 - 启动前执行
sudo -u www-data ulimit -n确认生效；若仍显示 1024，说明 limits.conf 未加载或用户启动方式不对
误区四：worker_connections 不同步放大，形成木桶短板
很多人只改 worker_processes auto;，却沿用默认的 worker_connections 512。结果是：8 核机器最多撑 4096 连接，远低于硬件能力，且容易触发 worker_connections are not enough 错误。
合理设置原则：
- 静态资源服务：可设为 10240～20480
- 动态接口或上游响应慢（如平均耗时 >500ms）：建议保守些，2048～4096 更稳
- 务必确保
worker_processes × worker_connections ≤ ulimit -n，并预留 20% 给日志、上游连接等额外 FD 消耗
