nginx 的 master process 不参与请求处理、不绑定 cpu 核心、不进行调度，仅负责读配置、启停 worker 进程及响应控制指令；真正处理请求和 cpu 调度优化由 worker 进程承担。
Nginx 的 Master Process 不参与请求处理，也不绑定 CPU 核心，更不会根据 CPU 核心做调度。
它本身是轻量级的管理进程，职责非常明确：读配置、开监听端口、拉起/监控 Worker 进程、响应 reload 或 stop 指令。它几乎不消耗 CPU，也不会被内核频繁调度到不同核心上运行——你甚至看不到它在 top 里持续占用 CPU。
真正和 CPU 核心打交道的是 Worker Processes，而 Master 只负责“派活”，不“干活”。
Master Process 的实际行为特点：
不处理任何客户端连接
所有网络 I/O、SSL 握手、反向代理、静态文件读取等，全部由 Worker 进程完成。默认不绑定 CPU（也无需绑定）
它没有worker_cpu_affinity这类指令，也没有必要。系统内核会按需将它调度到任意空闲核心，频率极低。生命周期长但活跃度低
启动后常驻内存，大部分时间处于休眠状态（等待信号），只在 reload、升级、日志轮转等事件触发时短暂唤醒。不参与负载均衡或连接分发逻辑
新连接到达时，由内核的accept()系统调用交给某个 Worker（通过accept_mutex协调），Master 不介入这一过程。
那谁在“根据 CPU 核心调度”？
是 Worker 进程 + 内核 + Nginx 配置协同作用：
-
worker_processes auto;或worker_processes 8;→ 决定启动几个 Worker -
worker_cpu_affinity auto;或手动掩码 → 把每个 Worker 固定绑到特定物理核心 -
use epoll;+multi_accept on;→ 让每个 Worker 高效收发大量连接 -
worker_rlimit_nofile 65535;→ 配合系统 limits，避免打开文件数卡脖子
这样，每个 Worker 独占一核（或按需分配），避免跨核缓存失效、减少上下文切换，才是真正的“CPU 调度优化”。
你可以验证一下：
# 查看所有 nginx 进程及其运行的核心（psr 列） ps axo pid,comm,psr,cmd | grep nginx | grep -v grep # 查看 master 进程（通常 PID 最小，且无 worker 关键字） # 它的 psr 值可能频繁跳变，或长期为 0，说明调度随意、无绑定
你会发现：Master 的 psr 值不稳定，而每个 Worker 的 psr 和你配置的 worker_cpu_affinity 严格对应。
不复杂但容易忽略：
Master 是“包工头”，Worker 才是“工人”。调优重点永远在 Worker 的数量、绑定、连接上限和事件模型上，而不是去给 Master 做 CPU 绑定或调度干预。
