Nginx Event Loop 高度依赖底层资源协调：CPU需稳定调度与核绑定，内存需保留余量并禁用swap，文件描述符与网络栈参数须匹配且内核协同调优，磁盘I/O应异步化避免阻塞。
Nginx 的 Event Loop 模型本身不额外消耗线程或进程资源，但它对底层系统资源的类型、分配方式和竞争状况高度敏感。它不追求“高配”，但特别忌讳资源争用与配置错位。
CPU：核心数与调度稳定性比主频更重要
Event Loop 在每个 worker 进程内单线程运行，依赖操作系统快速响应 epoll_wait() 返回并执行回调。若 CPU 调度不稳定，哪怕物理核心充足，也会导致事件积压：
- 平均负载（load average）持续超过 worker_processes 数值时，worker 进程易被频繁抢占，%wait 升高，P99 延迟跳升
- 推荐显式绑定 CPU 核心（worker_cpu_affinity auto 或手动配置），避免跨核缓存失效
- 避免同机部署 CPU 密集型任务（如转码、实时计算），防止调度器将 Nginx worker “挤出”时间片
内存：不是总量大就行，关键是可用性与页回收压力
Event Loop 处理快，但后续操作（如 SSL 握手、buffer 分配、gzip 压缩）需即时获取内存。一旦触发直接内存回收（direct reclaim），哪怕只卡几十毫秒，也会拖慢整个连接生命周期：
- 当可用内存低于内核 low watermark，kswapd 开始异步回收；进一步下降则触发同步回收，阻塞 socket buffer 分配路径
- 建议保留足够内存余量（例如总内存的 15%~20% 不分配给应用），尤其在开启 ssl_buffer_size 或大量 keepalive 连接时
- 避免 swap 启用——Nginx worker 进程被换出后唤醒延迟不可控，会直接破坏事件响应节奏
文件描述符与网络栈：上限必须匹配，且需内核协同
Event Loop 可管理数万连接，但前提是系统允许它注册那么多 fd，并能高效通知状态变化：
- worker_connections 值必须 ≤ ulimit -n（每个进程最大打开文件数），否则启动报错或静默降级
- 需调优内核参数：fs.file-max（系统级上限）、net.core.somaxconn（listen 队列长度）、net.ipv4.ip_local_port_range（临时端口范围）
- 启用 listen ... deferred 可减少 SYN 泛洪干扰，让内核只在收到完整首包后才通知 Nginx，降低无效事件开销
磁盘 I/O：非瓶颈，但同步操作会卡住 Event Loop
Nginx 默认磁盘读取是同步的。大文件 sendfile 或静态资源服务若未优化，会短暂阻塞当前 worker 的事件循环：
- 对大静态文件，启用 aio threads + thread_pool 将读取卸载到线程池，保持主线程响应能力
- 避免在 location 中使用 proxy_pass 同时又关闭 proxy_buffering——上游响应慢会导致 worker 长时间等待，无法处理其他事件
- 日志写入建议异步化（access_log /path.log main flush=1s），防止高频写日志引发 write() 阻塞
