Nginx优化需从系统资源、进程绑定、事件模型、实时监控四层面闭环验证：调高fd限制与内核队列，worker_processes匹配CPU核数并绑定，启用epoll+multi_accept，通过top/ss/stub_status和日志指标验证调度健康。
Nginx 进程与连接调度体系的评估与优化，核心是让每个 worker 进程“各司其职、不抢不等、不空不堵”，真正匹配硬件能力与业务流量特征。不能只改配置，而要从系统资源、Nginx 架构、连接生命周期、实际负载四个层面闭环验证。
一、先看系统底座是否撑得住
worker 进程和连接数不是孤立参数，它们直接受限于操作系统级资源：
- 每个 TCP 连接、每个打开的静态文件都占用 1 个文件描述符（fd）；
- 若
worker_processes设为 8、worker_connections设为 65535，理论需支持 524280 个 fd，但默认 Linux 单进程限制常为 1024； - 必须同步调优三处：
- 临时生效：
ulimit -n 655350（当前会话） - 永久生效：在
/etc/security/limits.conf中添加nginx soft nofile 655350 nginx hard nofile 655350
- 内核级连接队列：
sysctl -w net.core.somaxconn=65535（避免 SYN 队列溢出）
- 临时生效：
不配齐这三项，再高的 worker_connections 也无效。
二、进程数量与 CPU 绑定必须协同设计worker_processes auto 是起点，不是终点：
- 在 4 核服务器上设
worker_processes 4是合理起点，但若业务含大量磁盘 IO（如日志写入、大文件下载），可尝试6–8，用额外进程掩盖 IO 延迟； - 必须启用
worker_cpu_affinity auto（Nginx 1.9.10+），它会自动将每个 worker 绑定到独立 CPU 核心，避免跨核调度带来的 L3 缓存失效和上下文切换开销； - 若手动绑定（如 8 核场景），格式为：
worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000;确保每个 bit 位对应一个核心，且无重叠。
三、连接调度效率取决于事件模型与接收策略
Linux 下必须显式指定高效模型，并优化连接接纳行为：
-
use epoll;是必须项（非默认），它支持边缘触发（ET）模式，可支撑十万级并发而不退化； -
multi_accept on;让单次事件循环尽可能多地 accept 新连接，减少“惊群”后空转； -
accept_mutex on;（默认开启）防止多个 worker 同时争抢 accept，但在高并发下可考虑off+epoll组合提升吞吐（需压测验证）； - 若出现大量
TIME_WAIT连接堆积（如 >2 万），需配合内核参数：net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_fin_timeout = 30
允许 TIME_WAIT 状态 socket 重用于新 outgoing 连接。
四、用真实指标验证调度是否健康
光看配置没用，要盯住三类实时信号：
-
系统层：用
top -H观察各 worker 线程的 CPU 占用是否均衡（偏差 < 15% 为佳）；用ss -s查看total: XXXX和TCP: xxx (estab)是否接近理论最大值； -
Nginx 层：开启
stub_status，定期请求/nginx_status，重点关注：-
Active connections是否稳定在worker_processes × worker_connections × 0.7区间（过高易积压，过低说明资源闲置）； -
Reading值长期 > 10，可能 client header 缓冲区太小（调大client_header_buffer_size）；
-
-
业务层：通过
log_format加入$request_time和$upstream_response_time，统计 P95 延迟突增时段，反查是否 coincides withAccepts/Handled差值扩大（说明连接被丢弃或排队）。
不复杂但容易忽略。
