nginx 的 worker_processes 不支持按磁盘分区物理隔离，仅控制 cpu 进程数；真正实现静态资源物理隔离需结合 cpu 绑定、按盘部署资源、location 精确路由及内核 i/o 优化。
Nginx 的 worker_processes 本身不直接支持按磁盘分区做物理隔离，它控制的是 CPU 进程数量，而非文件路径或存储设备调度。所谓“结合磁盘分区实现静态资源的物理隔离加速”，本质不是靠 worker_processes 配置达成，而是通过进程绑定 + 资源部署 + 文件系统布局 + 内核I/O策略协同实现——worker_processes 只是其中一环，且必须配合其他措施才有效。
下面分三部分讲清楚怎么做、为什么这么做、哪些容易踩坑：
worker_processes 数量要匹配物理核心，为后续绑定打基础
每个 worker 进程应独占一个物理 CPU 核心（非超线程逻辑核），这是减少跨核缓存失效、提升本地磁盘访问效率的前提：
- 运行
lscpu | grep -E "(Socket|Core|CPU\(s\))"确认真实拓扑（例如：2 Socket × 4 Core × 2 HT = 16 逻辑 CPU，但仅 8 物理核） - 设
worker_processes 8（对应 8 物理核），而非auto或16 - 若服务器有多个 NVMe 盘（如
/dev/nvme0n1存图片、/dev/nvme1n1存 JS/CSS），不同盘通常挂载在不同 NUMA 节点；此时worker_processes不宜超过单个 NUMA 节点的物理核数，否则跨节点内存访问会拖慢磁盘元数据读取
按磁盘分区部署静态资源，并用 location + root 精确路由
真正实现“物理隔离”的是静态资源的存放位置和 Nginx 的请求路由方式：
- 将不同类型静态资源分别存放在不同挂载点：
-
/data/static-img/→ 绑定到高速 NVMe 盘（如/dev/nvme0n1p1） -
/data/static-js/→ 绑定到另一块 NVMe 盘（如/dev/nvme1n1p1） -
/data/static-fonts/→ 绑定到 SATA SSD（成本敏感型资源）
-
- 在配置中显式分离
location，避免混用 root：location ~* \.(jpg|jpeg|png|webp|gif)$ { root /data/static-img; expires 1y; add_header Cache-Control "public, immutable"; }
location ~* .(js|css|woff2|ttf)$ { root /data/static-js; expires 1y; }
这样每个请求只触达对应磁盘，不会因统一 root 导致所有静态请求争抢同一块盘的 I/O 队列。 ### 配合 CPU 绑定与内核调度，让 worker 与磁盘就近协同 光有目录隔离还不够，需让处理某类资源的 worker 进程，尽量运行在靠近对应磁盘控制器的 CPU 上： - 启用 `worker_cpu_affinity auto`（Nginx ≥1.9.10），它会自动轮询绑定物理核，避免手动写错掩码 - 若已知 `/dev/nvme0n1` 主要由 CPU 0–3 服务（查 `lscpu` 中 NUMA node 0 的 CPU 列表），可手动指定： ```nginx worker_processes 4; worker_cpu_affinity 0001 0010 0100 1000; # 仅用 NUMA node 0 的 4 个物理核
- 对应地，把
/data/static-img/挂载时启用noatime,nodiratime,iocharset=utf8，并确认其所在磁盘使用mq-deadline或none（NVMe 推荐none）调度器，减少 I/O 延迟抖动
⚠️ 注意：不要试图用
worker_processes控制“哪个 worker 处理哪块盘”——Nginx 没有盘感知路由机制。真正的隔离靠的是「请求路径 → location 匹配 → root 路径 → 文件系统挂载点 → 物理磁盘」这一整条链路的显式划分，worker 只负责高效执行这条链路上的读取任务。
不复杂但容易忽略。
