Nginx 的 Master Process 如何管理工作进程资源

Master Process 通过配置驱动、进程派生和运行时约束统筹资源管理，自身几乎不消耗计算资源；启动时解析 nginx.conf 设置 worker_processes、worker_rlimit_nofile 等限制，共享监听套接字并协调 accept，运行时监控 Worker 状态实现自动恢复与日志统管。

Master Process 不直接分配 CPU 或内存资源给 Worker，而是通过配置驱动、进程派生和运行时约束来统筹管理资源使用。它本身几乎不消耗计算资源，真正的资源调度发生在启动阶段和信号响应过程中。

配置决定资源边界

Master 在启动时读取 nginx.conf，将资源配置指令转化为内核可识别的限制，并在 fork Worker 前完成设置：

• worker_processes auto：自动匹配 CPU 核心数，避免多于物理核心的 Worker 造成上下文切换开销
• worker_rlimit_nofile：调用 setrlimit() 设置每个 Worker 可打开的最大文件描述符数，直接影响并发连接上限
• worker_cpu_affinity：通过 sched_setaffinity() 将 Worker 绑定到指定 CPU 核心，减少缓存抖动，提升 L1/L2 缓存命中率
• worker_priority：调整 nice 值，间接影响内核调度器对 Worker 的 CPU 时间片分配权重

共享监听套接字，避免资源重复创建

Master 在 fork 之前就已完成 socket 的 create、bind 和 listen，所有 Worker 进程通过文件描述符继承获得同一组监听端口。这种设计带来两个关键好处：

• 每个监听端口只占用一个 fd，不随 Worker 数量线性增长
• Worker 共享同一套 accept 队列，由内核维护连接排队，Master 通过 accept_mutex 协调 Worker 轮流调用 accept()，防止“惊群”

运行时回收与兜底保障

Master 持续监控 Worker 状态，确保资源使用始终符合配置预期：

• 通过非阻塞 waitpid(-1, &status, WNOHANG) 定期检查子进程退出状态
• 若 Worker 因段错误、OOM 或被 kill -9 异常终止，Master 立即 fork 新进程补足 worker_processes 数量
• 新 Worker 启动时继承相同的 rlimit、CPU 亲和性等资源约束，保证行为一致性
• 日志写入由 Master 统一接管（Worker 写 pipe，Master 落盘），避免多个进程竞争磁盘 I/O

不干预 Worker 内部资源使用

Master 不控制 Worker 的内存分配策略、连接池大小或事件循环细节。这些由 Worker 自行管理：

• 每个 Worker 独立维护自己的连接池、内存池和定时器队列
• worker_connections 控制单个 Worker 的最大并发连接数，但实际内存占用取决于请求头大小、缓冲区配置等
• 共享内存（如 limit_req、ssl_session_cache）由 Master 初始化并映射给所有 Worker，但读写逻辑在 Worker 中执行