nginx事件循环是内建不可关闭的运行机制，调优聚焦于events块配置、worker协同与系统资源适配：linux必须显式启用epoll；worker_connections需匹配ulimit和fs.file-max限制；启用multi_accept与accept_mutex减少惊群效应；worker_processes设为cpu核心数并绑定cpu_affinity。
Nginx 的事件循环（Event Loop）不是可开关的功能，而是其工作进程内建的运行机制——它天然存在、默认启用、无法关闭。性能调优的关键，在于让这个循环更高效地响应、分发和处理连接事件，而不是“配置它是否存在”。核心动作集中在 events 块配置、worker 进程协同 和 系统资源适配 三个层面。
选对底层事件模型：Linux 必用 epoll
Linux 环境下，epoll 是唯一能支撑十万级并发的高效模型。它基于内核就绪列表，时间复杂度 O(1)，避免了 select/poll 的轮询开销。
- 显式写入
use epoll;，不依赖自动探测——防止因编译选项或容器镜像内核兼容性导致降级为低效模型 - Docker 部署时确认基础镜像内核 ≥ 2.6，且未禁用 epoll（绝大多数主流镜像默认支持）
- 若误用 select 或 poll，连接数超 2000 后性能会断崖式下降，延迟明显抖动
合理设置 worker_connections 与系统限制匹配
该值决定单个 worker 能同时管理多少 socket 连接，但它的实际生效上限由操作系统文件描述符（fd）总数严格限制。
- 先查当前限制：
ulimit -n（用户级）和sysctl fs.file-max（系统级） - 在
/etc/security/limits.conf中为 nginx 用户设置：nginx soft nofile 65536nginx hard nofile 65536 - 检查 systemd 服务是否覆盖限制：查看
/etc/systemd/system/nginx.service是否含LimitNOFILE=，如有需同步调整 - 建议值参考：4 核 CPU +
worker_processes auto;→ 每 worker 设worker_connections 10240，理论并发约 4×10240 = 40960，再预留 15% fd 给日志、上游连接等
启用 multi_accept 与 accept_mutex 协同减少争抢
新连接到达时，Linux 默认唤醒所有空闲 worker（惊群效应），但仅一个能成功 accept。这对短连接高吞吐场景尤为低效。
-
multi_accept on;：让每个 worker 在一次事件唤醒中尽可能多地 accept 就绪连接，降低唤醒频次和上下文切换 -
accept_mutex on;（默认开启）：配合 multi_accept，使 worker 轮流获取 accept 锁，避免多个进程集中争抢同一连接队列 - 两者共用后，在 API 网关类负载下，可观测到 CPU 使用曲线更平稳、平均延迟下降 10%~20%
绑定 CPU 亲和性并控制 worker 数量
每个 worker 进程应尽量独占一个物理 CPU 核心，避免跨核调度带来的缓存失效和锁竞争。
- 设
worker_processes auto;（推荐），Nginx 自动匹配逻辑 CPU 数；或手动指定为物理核心数（如 8 核服务器设为 8） - 启用
worker_cpu_affinity auto;（Nginx 1.12.2+），自动将各 worker 绑定到不同 CPU 核心 - 避免设过多 worker：超过 CPU 核心数反而增加调度开销；也不宜过少，否则无法充分利用多核
- 搭配
worker_rlimit_nofile 65535;，突破单进程默认 fd 限制，确保配置生效
