Nginx性能需通过间接指标判断：关键看请求端到端路径是否稳定低延迟，而非Event Loop本身速度；核心指标包括stub_status中的Active/Waiting比例、ss -s的skipped/synrecv、pidstat的%wait及dmesg告警，调优需匹配worker配置与系统参数。

Nginx 的 Event Loop 本身不暴露“毫秒级循环耗时”这类直接指标，它的性能必须通过可观测的间接信号来判断——本质是看事件能否及时被分发、处理、响应。真正关键的不是 Loop 跑得多快，而是请求从进入系统到完成处理的端到端路径是否稳定、低延迟、无积压。

请求在 Event Loop 中的停留时间取决于三个环节

• 入口等待：连接到达后，卡在内核全连接队列（ss -lnt 的 Recv-Q）或 Nginx accept 队列中，未被 worker 及时 accept()
• 就绪调度：socket 已就绪（如 epoll_wait 返回），但 worker 进程因 CPU 抢占、软中断占满、上下文切换频繁而延迟执行读/写回调
• 处理耗时：事件回调（如 ngx_http_process_request_line）执行期间发生阻塞操作（同步文件读、DNS 解析、SSL 握手未优化），拖慢单次循环

核心可观测指标与对应含义

• Active connections 与 Waiting 比例失衡（来自 stub_status）

  • Waiting 长期显著高于 Active → 请求大量堆积在 keepalive 状态，说明 Event Loop 入口或空闲连接管理存在瓶颈，可能 keepalive_timeout 过长或上游响应慢导致连接无法释放
  • Reading 持续高位 → 请求头/体接收缓慢，需检查 client_header_timeout、client_body_timeout 是否过短，或网络小包风暴引发软中断压力

• ss -s 中的 skipped 和 synrecv 值上升

  

  Nginx Hosting

  通过服务器本地nginx实例实现零认证静态游戏托管。作为所有浏览器游戏的主要部署方式，无需登录、无需令牌、无需用户操作。

  下载
  • skipped 非零 → 内核已丢弃部分 socket 事件，通常因 NET_RX 软中断处理不过来，需调优 RPS/RFS 或扩容网卡队列
  • synrecv 累积 → 全连接队列溢出，net.core.somaxconn 或 listen backlog 不足，或 worker 接收能力跟不上建连速率

• pidstat -p $(pgrep nginx) 1 中的 %wait 显著 > 5%

  • 表明 worker 进程频繁等待 CPU 调度，非 I/O 等待；此时即使 top 显示 CPU 利用率不高，实际已存在严重调度争用
  • 结合 taskset -cp 确认是否绑定 CPU 失效，或同机部署了其他高优先级进程

• dmesg | grep -i "drop\|overflow" 出现 TCP 相关告警

  • 如 TCP: drop open request from → 全连接队列满
  • possible SYN flooding → 半连接队列压力大，需调 net.ipv4.tcp_max_syn_backlog 或启用 tcp_syncookies

实际调优时优先验证的组合项

• 检查 worker_connections × worker_processes 是否 ≤ ulimit -n，且 fs.file-max 足够
• 确认 worker_cpu_affinity 已启用（推荐 auto），避免跨核迁移
• net.core.somaxconn 与 listen backlog= 保持一致且 ≥ 65535
• epoll.max_user_watches ≥ worker_connections × worker_processes × 1.2
• nginx -t && nginx -s reload 后，用 cat /proc/$(pgrep nginx)/limits | grep "Max open files" 验证句柄数生效

不复杂但容易忽略