文件描述符限制是影响Nginx QPS和RT的关键瓶颈，每连接占用至少1个fd，系统级ulimit -n不足会导致连接拒绝、QPS下降、RT飙升及502错误；调优需同步修改limits.conf、systemd配置、worker_rlimit_nofile，并验证生效。
文件描述符（file descriptor）是 Nginx 高并发能力的底层基石之一。它不是“调了就快”的魔法参数，而是系统资源与连接承载能力之间的硬性桥梁——worker_connections 再高，若系统级文件描述符限制（ulimit -n）没跟上，Nginx 会直接拒绝新连接，报错 “Too many open files”。压测中常见 QPS 上不去、RT 突增甚至 502 大量出现，十有八九卡在这一步。
为什么文件描述符限制直接影响 QPS 和 RT
Nginx 每个活跃连接（包括 keep-alive 空闲连接、正在传输的请求、SSL 握手中的 socket）都占用至少 1 个文件描述符。当系统允许打开的 fd 总数低于并发连接需求时：
- 新连接被内核拒绝，客户端重试或超时，表现为 QPS 下降、连接建立失败率上升；
- worker 进程频繁陷入“等待可用 fd”状态，调度延迟增加，RT 波动明显，尾部延迟（P99/P999）飙升；
- 日志中高频出现
accept() failed (24: Too many open files)，这是最直接的信号。
调优前后的典型压测对比（8核服务器，静态资源代理场景）
以某生产级 API 网关为例，初始配置未调整系统限制：
- 调优前：ulimit -n = 1024，worker_processes auto（8），worker_connections = 1024 → 理论最大连接 = 8 × 1024 = 8192，但实际受限于系统级 1024，多数 worker 进程无法满载；压测结果：QPS ≈ 2800，平均 RT = 112ms，P99 RT > 480ms，错误率 3.7%；
- 调优后：ulimit -n = 200000，worker_connections = 20000，保持 worker_processes auto；压测结果：QPS 提升至 22500（+700%），平均 RT 降至 24ms，P99 RT 稳定在 68ms，错误率归零。
关键操作步骤与验证要点
调优不是改完配置就完事，必须闭环验证：
- 修改系统级限制：在
/etc/security/limits.conf中添加nginx soft nofile 200000和nginx hard nofile 200000（假设运行用户为 nginx）； - 确保 systemd 服务不覆盖限制：若用 systemctl 启动，在
/usr/lib/systemd/system/nginx.service的[Service]段加入LimitNOFILE=200000； - Nginx 配置中显式设置
worker_rlimit_nofile 200000;，让主进程主动告知 worker 上限； - 重启 Nginx 后验证：执行
cat /proc/$(pgrep nginx)/limits | grep "Max open files"，确认软硬限制均已生效； - 压测时监控
ss -s输出的total: 19xxx（当前已用 fd 数），确保其始终低于 200000，且无突增回落现象。
配合 keepalive_timeout 的协同调优
文件描述符释放速度，取决于连接何时关闭。keepalive_timeout 设置过长，会导致大量 fd 被空闲连接长期占用：
- 对短连接为主的 API 网关，建议设为
keepalive_timeout 15s;； - 若后端是 gRPC 或长轮询服务，可适当延长至 30–60s，但需同步评估 fd 持有时间与峰值并发比；
- 搭配
keepalive_requests 100;（单连接最多处理请求数），防止单连接长期霸占 fd 资源。
