worker_processes需按磁盘控制器并行能力配置：单控制器设为物理核心数，双独立NVMe可设为物理核数×1.5，并须配合aio threads、directio和open_file_cache等关键配置优化IO路径。
worker_processes 本身不直接感知磁盘控制器数量，它调度的是 CPU 资源，而非磁盘通道。但静态资源 IO 密集场景下，磁盘控制器（如多块 NVMe、RAID 卡、不同 SATA 通道）的并行能力会影响整体吞吐，此时 worker_processes 的配置需围绕“避免磁盘争用”和“匹配 IO 并发潜力”来调整，而非简单按 CPU 核数拉满。
先确认磁盘控制器拓扑与 IO 能力
不要只看 CPU 核数。执行以下命令识别真实 IO 路径：
- lspci | grep -i "storage\|nvme\|raid" —— 查看是否有多条独立 NVMe 总线或多个 RAID 控制器
- lsblk -d -o NAME,ROTA,TRAN —— 区分 SSD（ROTA=0）与 HDD（ROTA=1），TRAN 显示接口类型（sata/nvme/usb）
- cat /sys/block/nvme0n1/device/numa_node && cat /sys/block/nvme1n1/device/numa_node —— 若跨 NUMA 节点，说明控制器物理隔离度高
若发现 2 块 NVMe 分属不同 PCIe Root Complex 或不同 NUMA 节点，说明它们具备真正并行 IO 能力；若共用同一 SATA 主控或同一 NVMe 控制器的多个 namespace，则并发收益有限。
静态文件服务中 worker\_processes 的合理取值
当 Nginx 大量读取磁盘文件（尤其是未启用 sendfile 或未命中 open_file_cache 时），每个 worker 进程会触发同步 read() 系统调用，容易阻塞。此时过多 worker 会加剧磁盘队列竞争，反而降低吞吐。
- 单控制器（如 1 块 SATA SSD 或 1 个 NVMe 设备）：设为 物理核心数（非逻辑线程数），例如 4 核 CPU →
worker_processes 4; - 双独立控制器（如 nvme0n1 + nvme1n1，且跨 PCIe 通道）：可尝试设为 物理核心数 × 1.5（如 4 核 →
worker_processes 6;），前提是已启用aio threads;和directio 4k;避免内核页缓存抖动 - 混合存储（SSD + HDD）：建议分离服务——SSD 托管高频静态资源，HDD 仅存归档；worker_processes 按 SSD 所连控制器能力配置，HDD 不参与并发调度
必须配套的关键配置
仅调 worker_processes 无效，必须协同优化 IO 路径：
-
启用异步 IO：在 events 块中添加
aio threads;（Nginx 1.17.8+），配合use epoll;，让 worker 在等待磁盘时释放 CPU -
绕过页缓存（对大文件更稳）：在 location 中加
directio 4m;，避免小块读放大，尤其适合 >1MB 的图片/视频 -
强化文件元数据缓存：全局配置
open_file_cache max=10000 inactive=30s;+open_file_cache_valid 60s;，大幅减少 stat() 系统调用 -
绑定 CPU 与控制器亲和性：若控制器分布在不同 NUMA 节点，用
worker_cpu_affinity将 worker 分配到对应节点 CPU，例如worker_cpu_affinity 00000001 00000010 00000100 00001000;（前 4 个 worker 绑定到 node 0 的 4 个核）
验证是否真受益于多控制器并行
不要依赖理论值。压测时关注三项指标：
- 用
iostat -x 1观察各设备的%util和await：理想状态是多个设备%util同时接近 70–90%，await稳定低于 10ms - 用
nginx -V 2>&1 | grep -o with-threads确认编译支持线程池 - 对比不同 worker_processes 下的
wrk -t8 -c2000 -d30s结果：若从 4→6 提升 QPS 超过 15%，且iostat显示双设备负载均衡，才说明控制器并行生效
本质上，磁盘控制器数量是 IO 并发的“天花板”，而 worker_processes 是“水龙头开度”。开太大，水（IO 请求）堵在管道里；开太小，水流不满。调优目标不是填满 CPU，而是让每条磁盘通路都跑在高效区间。
