Nginx在高并发短连接下性能瓶颈不在epoll本身，而在高频创建/销毁连接引发的系统调用、fd回收、TIME_WAIT堆积及accept队列溢出等开销；优化应聚焦keepalive复用、内核参数调优与连接限流。
在高并发短连接场景下，Nginx 使用 epoll 模型本身不会显著增加 CPU 或内存开销，但连接频次过高会放大内核和用户态的资源管理成本——关键不在 epoll 机制，而在连接生命周期过短导致的系统调用与资源回收压力。
epoll 本身轻量，但短连接让“创建/销毁”成为瓶颈
epoll 的优势是 O(1) 事件通知、无需遍历全部 socket，适合大量空闲连接。但短连接（如 HTTP/1.0、无 keepalive 的请求）意味着每个请求都经历：
- 用户态 accept() 获取新 socket
- 内核分配 file descriptor、socket buffer、tcp control block
- 请求处理完立即 close()，触发四次挥手、time_wait、fd 回收、内存释放
这一整套流程由系统调用驱动，高频发生时，上下文切换、fd 分配/回收、time_wait 状态维护 成为主要开销源，而非 epoll_wait() 本身。
实际可观测的资源压力点
常见瓶颈通常体现在以下几方面：
- 文件描述符耗尽：短连接虽不长时占用 fd，但突发流量下瞬时 fd 分配速率可能触达 ulimit -n 上限
- TIME_WAIT 连接堆积：每关闭一个 TCP 连接进入 TIME_WAIT（默认 60 秒），高 QPS 下可积累数万连接，占用端口和内核内存
- 内核 socket 缓冲区分配压力：频繁 alloc/free sk_buff 和 socket 结构体，加剧 slab 分配器竞争
- accept 队列溢出：syn backlog 和 accept queue 若设置过小，SYN 包被丢弃，表现为连接超时或重传
针对性优化建议
不是禁用 epoll，而是减少短连接带来的无效开销：
- 启用 keepalive（keepalive_timeout、keepalive_requests），复用连接，将“每请求一连接”转为“多请求一连接”
- 调整内核参数缓解 TIME_WAIT 压力：
net.ipv4.tcp_tw_reuse = 1（仅客户端有效，服务端慎用）
net.ipv4.tcp_fin_timeout = 30（缩短 FIN_WAIT_2 超时）
net.core.somaxconn 和 net.core.netdev_max_backlog 加大以应对突发 SYN
- Nginx 层限制单 IP 连接数（limit_conn）和请求频率（limit_req），防探测或误用放大短连接冲击
- 确保 ulimit -n 足够（如 65535+），并检查 worker_rlimit_nofile 与之匹配
对比：长连接 vs 短连接下的 epoll 表现
同一台 Nginx：
- 处理 10 万并发长连接（keepalive）：epoll_wait 高效轮询，内存占用稳定，CPU 主要在业务逻辑
- 处理 10 万 QPS 短连接（平均连接寿命 100ms）：每秒新建/关闭千级连接，sys CPU 升高、/proc/net/sockstat 中 used 和 timewait 数值剧烈波动、dmesg 可能出现 “TCP: too many of orphaned sockets”
这说明问题本质是连接模型与负载特征不匹配，而非 epoll 不适合高并发。
