worker_processes 是 nginx 启动的工作进程数量，决定并行处理请求的宽度；不能乱设，因设小导致多核闲置、设大引发上下文切换开销、内存争抢甚至 oom killer 终止进程。
worker_processes 是什么，为什么不能乱设
worker_processes 指令控制 Nginx 启动多少个工作进程（worker process），每个都独立处理客户端请求。它不是“越多越好”，而是要匹配服务器的 CPU 核心数和实际负载类型。设成 auto 最常见也最稳妥，Nginx 会自动读取 CPU 核心数；设成具体数字（如 4）则需人工确认物理/逻辑核心数量；设得过高（比如 32 核机器配 64 个 worker）反而引发上下文切换开销、内存争抢，甚至触发 OOM Killer 杀掉进程。
配置生效前必须做的三件事
改完 worker_processes 后，不能直接 reload 就完事。必须依次验证：
- 运行 nginx -t 确认语法无误，避免因拼写错误或嵌套层级问题导致启动失败
- 检查系统级文件描述符限制：ulimit -n 查当前值，若低于 65535，需在 /etc/security/limits.conf 中补充
* soft nofile 65535并重启会话 - 同步更新 worker_rlimit_nofile 指令值，确保 Nginx 进程自身能打开足够多的连接，否则即使配置了高 worker_connections 也会卡在 accept 阶段
worker 进程异常退出的典型信号与应对
当发现 ps aux | grep nginx 中 worker 进程频繁启停、或 error.log 出现 worker process is shut down、aborting 等记录，优先排查以下方向：
- 后端服务超时：PHP-FPM 响应慢、数据库连接池耗尽，导致 Nginx 等待超时后主动关闭 worker。检查 proxy_read_timeout 和 fastcgi_read_timeout 是否合理
- 连接残留未清理：平滑 reload 后旧 worker 进入 shutdown 状态是正常行为，但若被手动 kill -9，则会留下 open socket left in connection 日志。切勿干预 shutdown 状态的 worker，应等待其自然退出
- 资源硬限制突破：用 top -p $(pgrep -f "nginx: worker") 观察单个 worker 内存占用是否持续上涨，配合 dmesg | grep -i "killed process" 确认是否被 OOM Killer 终止
如何验证 worker 数量是否按预期运行
配置生效后，别只信配置文件，要用系统视角交叉验证：
- 查主配置中定义的值：grep worker_processes /etc/nginx/nginx.conf
- 看实际运行数量：ps -ef | grep '[n]ginx: worker' | wc -l
- 比对是否一致；如果不符，常见原因是 systemd 服务单元覆盖了配置（如 /lib/systemd/system/nginx.service 中设置了 Environment=WORKERS=2），此时需修改 service 文件并执行 systemctl daemon-reload
