Nginx多进程调优关键在于匹配硬件与负载：worker_processes设为CPU物理核心数（非超线程数），配合worker_cpu_affinity绑定核心；调高worker_connections并同步提升系统ulimit；启用sendfile+tcp_nopush实现零拷贝传输；利用open_file_cache和gzip_static降低IO压力。
利用Nginx的多进程模型合理配置，能显著提升静态资源（如图片、CSS、JS）的并发响应能力，但关键不在“开更多进程”，而在于匹配硬件与负载特征。
理解worker_processes与CPU核心的关系
Nginx默认使用worker_processes auto，即自动设为CPU逻辑核心数。这是最稳妥的起点——每个worker进程绑定一个CPU核心，避免上下文频繁切换。若服务器是4核8线程，通常设为4而非8；超线程对Nginx这类I/O密集型服务收益有限，盲目设高反而可能因缓存争用降低性能。
- 查看逻辑核心数：nproc 或 lscpu | grep "CPU(s):"
- 生产环境建议显式配置，避免auto在容器等环境中误判
- 单机高并发静态服务（如CDN边缘节点），可结合worker_cpu_affinity绑定特定核心，减少跨核缓存失效
调高worker_connections并匹配系统限制
每个worker进程能同时处理的连接数由worker_connections控制，默认512太保守。静态资源请求轻量，应结合系统级限制一起调优：
- 先检查系统最大文件描述符限制：ulimit -n，必要时在/etc/security/limits.conf中提高（如nginx soft nofile 65535）
- 计算总并发能力：worker_processes × worker_connections，例如4进程×1024连接 = 4096并发
- 注意：该值不宜远超实际峰值QPS×平均连接保持时间（keepalive_timeout），否则空闲连接堆积占用内存
启用sendfile与tcp_nopush，减少数据拷贝和网络包碎片
静态文件传输不经过用户态缓冲，直接由内核DMA发送，是Nginx加速的关键路径：
- 开启sendfile on：绕过read()+write()系统调用，零拷贝传输
- 搭配tcp_nopush on：确保sendfile发送的数据包填满MTU，避免小包堆积（需同时开启keepalive）
- 禁用tcp_nodelay（默认off）：对静态资源无意义，开启反而增加小包数量
合理设置缓存与压缩，降低重复IO压力
多进程本身不解决磁盘IO瓶颈，需配合缓存策略让多数请求不落盘：
- open_file_cache缓存文件句柄、大小、修改时间，减少stat()和open()系统调用
- 对高频静态资源（如favicon.ico、common.css），用expires或add_header Cache-Control推动浏览器长期缓存
- 启用gzip_static on，提前用gzip预压缩文件，避免运行时压缩CPU开销
