避坑指南：解决由于 worker_processes 设置不当导致的静态 IO 竞争瓶颈-Nginx-PHP中文网

静态IO瓶颈根源是worker_processes与IO特性不匹配：进程过多引发磁盘随机寻道冲突，过少则CPU闲置；应按IO带宽而非CPU核心数调优，HDD建议2～4个、SSD可试8个，并同步调高文件描述符、somaxconn及启用sendfile/tcp_nopush。

避坑指南：解决由于 worker_processes 设置不当导致的静态 io 竞争瓶颈

静态 IO 竞争瓶颈常被误判为磁盘慢或带宽不足，实际根源往往是 worker_processes 与业务 IO 特性不匹配。Nginx 本身不缓存大文件，当大量小图、CSS、JS 被高频读取且总大小远超内存时，每个 worker 都会独立触发磁盘寻道——进程数过多，就会在底层产生大量随机 IO 冲突；过少，则单核饱和、其余 CPU 闲置。

先看你的负载类型：静态文件服务 ≠ 均匀 IO

不是所有静态场景都适合“设成 CPU 核心数”。关键区分两点：

文件规模：若网站静态资源总量（如图片库+前端包）明显大于可用内存（比如 64GB 内存但静态文件共 200GB），磁盘读取无法靠 page cache 缓解，IO 成为瓶颈主体
访问模式：是否大量并发请求分散在不同小文件上（如商品图、头像、图标）？这种模式下，单个 worker 在处理多个连接时会频繁切换读取位置，加剧磁盘寻道竞争

此时，单纯增加 worker 进程数反而放大 IO 冲突——多个进程同时发起随机读，硬盘响应延迟飙升，%wa（IO 等待）显著升高，而 CPU 利用率却不高。

推荐配置策略：按 IO 带宽而非 CPU 核心数来定

目标是让磁盘吞吐接近物理极限，又避免过度争抢。实测有效的做法：

从 worker_processes 1 开始压测，观察 iostat -x 1 中的 await 和 %util，确认单进程能否打满磁盘 IO
逐步增加到 2、4、8，同步监控 iotop 下各 nginx worker 的实际 IO BPS，若新增进程带来的增量 IO 微乎其微（比如提升＜5%），说明已达 IO 瓶颈上限
对机械盘（HDD）环境，通常 2～4 个 worker 即可；SSD 可试到 8，但超过后 r/s（每秒读请求数）不再线性增长，反而 avgqu-sz（平均队列长度）跳升，就是争抢信号

必须同步调优的配套项

worker_processes 不是孤立参数，以下三项不匹配，调再准也白搭：

系统文件描述符限制：运行 ulimit -n 查当前值，确保 worker_connections × worker_processes ≤ ulimit -n × 0.7（预留 30% 给日志、上游连接等）
内核 listen 队列：执行 sysctl net.core.somaxconn，建议设为 65535，并在 nginx listen 指令后加 backlog=65535
启用 sendfile + tcp_nopush：在 http 或 server 块中加入
sendfile on;
tcp_nopush on;
tcp_nodelay on;
这能让内核直接 DMA 传输文件，绕过用户态拷贝，大幅降低 CPU 在静态文件分发中的开销