一、worker_processes —— CPU 利用率的上限
1. 参数作用
worker_processes：决定Nginx启动多少个工作进程。
每个进程处理独立的事件循环，通常与CPU核心数匹配或略多。
worker_processes auto;
每个 worker 是一个独立进程，一个 worker 同一时刻只跑在一个 CPU 核上。
2. 正确配置原则
CPU 核数 = worker 数
推荐直接用 auto;
错误配置示例：
1 核 CPU，起 8 个 worker → 上下文切换爆炸;
32 核 CPU，只起 2 个 worker → 资源严重浪费;
二、worker_connections —— 并发连接能力的核心
1. 参数作用
worker_connections：每个工作进程可同时处理的最大连接数。
2. 理论最大并发
最大连接数 = worker_processes × worker_connections。
例如：
8 核 CPU；
8 个 worker；
每个 65535
→ 理论并发 ≈ 52 万连接
3. 必须配套的系统参数
如果只调 Nginx，不调系统参数，等于白调：
ulimit -n；
fs.file-max；
否则会直接遇到：
“too many open files”
三、use epoll —— 事件模型决定并发天花板
1. 参数配置
events {
use epoll;
}
Linux 下必须显式使用 epoll。
2. 为什么 epoll 关键
O(1) 事件通知，支撑百万级并发连接。
避免 select / poll 的线性扫描。
3. 性能差距有多大
在高并发场景下：
select / poll：CPU 迅速打满
epoll：CPU 利用率极高、稳定
这是数量级差异，不是百分比优化
四、accept_mutex —— 解决惊群效应
1. 什么是惊群
多个 worker 同时被唤醒抢同一个连接：
大量无效唤醒
CPU 白白消耗
2. 关键配置
accept_mutex on;
只允许一个 worker 接受新连接
其他 worker 继续处理已有请求
3. 适用场景
高并发短连接
QPS 高、连接频繁创建销毁。
mikechen睿哥
10年+一线大厂架构实战经验，就职于阿里、淘宝等一线大厂，操盘多个亿级大厂核心项目。