文件描述符耗尽需系统、用户、Nginx三层协同调优：先调高fs.file-max，再配置limits.conf限定nginx用户nofile值，最后在nginx.conf中设置worker_rlimit_nofile和worker_connections并校验公式。
这个问题本质是文件描述符（file descriptor，FD）耗尽，不是 Nginx 单独的问题，而是系统资源限制、用户级限制、进程级配置三层叠加的结果。必须逐层检查并闭环调整，缺一不可。
查清当前瓶颈在哪一层
先快速定位卡点位置：
- 运行 ulimit -n —— 看当前 shell 会话的软限制（常为 1024）
- 运行 cat /proc/sys/fs/file-max —— 看系统全局最大 FD 数（CentOS 默认约 9.5 万）
- 查 Nginx master 进程限制：cat /proc/$(cat /var/run/nginx.pid)/limits | grep "Max open files"
- 查 worker 进程限制：ps --ppid $(cat /var/run/nginx.pid) -o %p | sed '1d' | xargs -I{} cat /proc/{}/limits | grep "Max open files"
如果前三者都远低于 65535，说明限制压在系统或用户层；如果只有 worker 进程显示 1024，而其他都已调高，那问题就在 Nginx 配置没生效。
系统级文件描述符上限（内核参数）
这是最底层的天花板，必须先调高：
- 临时生效（测试用）：sysctl -w fs.file-max=6815744
- 永久生效：编辑 /etc/sysctl.conf，添加一行 fs.file-max = 6815744，再执行 sysctl -p
- 注意：该值不宜设得过高（如超内存 10%），否则可能引发 OOM；可用 grep MemTotal /proc/meminfo | awk '{print int($2/10)}' 估算推荐值
用户级打开文件数限制（limits.conf）
Nginx 启动时继承的是运行用户的限制，不是 root 的。即使 root 调了 ulimit，nginx 用户仍受限：
- 编辑 /etc/security/limits.conf，追加四行（推荐显式指定 nginx 用户）：
nginx hard nofile 65535
* soft nofile 65535
* hard nofile 65535
- 保存后需重新登录用户或重启 systemd 服务（如使用 systemd 启动 Nginx，还需设置 LimitNOFILE=65535 在 service 文件中）
- 验证方式：切换到 nginx 用户（sudo -u nginx bash），再运行 ulimit -n，应输出 65535
Nginx 自身配置联动（nginx.conf）
光调系统还不够，Nginx 必须主动申请更高权限，并合理分配连接：
- 在 nginx.conf 全局块（main context）加入：worker_rlimit_nofile 65535;
- 在 events 块中设置：worker_connections 4096;（单个 worker 最大并发连接数）
- 确保 worker_processes 合理（建议 auto 或等于 CPU 核心数），避免 worker 过多导致总 FD 需求超标
- 关键校验公式：worker_rlimit_nofile ≥ worker_connections × worker_processes（例如 4 核 + auto → 4 个 worker，4096×4 = 16384，65535 完全覆盖）
改完务必执行 nginx -t 测试语法，再 systemctl reload nginx 或 nginx -s reload。
