fs.file-max是系统级文件描述符总上限，决定Nginx高并发能力的底层基础；需按“预期峰值并发×2.5+10000”估算，如5万并发推荐设为2097152，并同步配置worker_rlimit_nofile和ulimit。
Linux内核参数 fs.file-max 直接决定系统能同时打开的最大文件描述符（file descriptor，简称 fd）总数。Nginx 每个连接至少占用 1 个 fd（客户端连接），作为反向代理时更常占用 2 个（客户端 + 后端连接），再加上日志文件、配置加载、缓存文件句柄等，fd 消耗非常可观。若 file-max 设置过低，Nginx 在高并发下会因无法分配新 fd 而拒绝连接，表现为 502、连接超时或 accept() failed (24: Too many open files) 错误——这不是 Nginx 配置问题，而是系统资源已耗尽。
为什么 file-max 不只是“够用就行”
内核用哈希表管理所有打开的 fd，file-max 决定了该哈希表的初始大小和扩容上限。值太小会导致：
- 哈希冲突升高，查找 fd 的时间变长，影响 accept、read、write 等系统调用延迟
- 内核频繁触发 fd 表重哈希（rehash），带来短时 CPU 尖峰和锁竞争
- 与 Nginx 的
worker_rlimit_nofile不匹配时，worker 进程实际可用 fd 上限被 silently 截断
合理设置 file-max 的关键依据
不能拍脑袋设大，需结合预期并发量和部署模式：
- 估算公式：建议
file-max ≥ (预期峰值并发 × 2.5) + 10000（留出系统日志、监控等基础开销） - 典型参考：支撑 5 万并发代理场景，推荐设为 2097152（200 万）；突破 10 万并发，建议 ≥ 4194304
- 必须同步配置 Nginx：
worker_rlimit_nofile 1048576;（每个 worker 最多用 100 万 fd），并确保运行用户在/etc/security/limits.conf中有对应nofile限制
验证与调优要点
改完后务必验证是否生效且无副作用：
- 运行
sysctl fs.file-max确认值已加载；用cat /proc/sys/fs/file-nr查看当前已用 fd 数（三列中第一列为已分配数） - 压力测试时观察
dmesg | grep -i "file"是否有警告，如"VFS: file-max limit reached" - 避免设得过大（如 >800 万）：可能增加内核内存占用（每个 fd 约占 1KB），尤其在内存紧张的容器环境中
file-max 是静态资源池的“总闸门”，它不参与实时调度，但一旦卡死，所有上层优化都失效。设对了，是隐形的性能地基；设小了，再好的 Nginx 配置也跑不出高并发。
