Linux高并发下FD不足需四层协同优化：系统级调高file-max和nr_open；用户级配置limits.conf；systemd服务单独设LimitNOFILE；应用层如Nginx加worker_rlimit_nofile，Java、Netty等适配FD使用，并扩ip_local_port_range防端口耗尽。
Linux 高并发场景下，文件描述符（FD）不足会导致“Too many open files”错误，直接限制连接数、拖慢响应甚至服务中断。优化不是调大一个参数就行，而是分层协同：系统级、用户级、进程级、应用级四层都要对齐，缺一不可。
系统级全局上限：决定整机能力天花板
这是所有文件描述符的总池子，必须最先调高，否则上层再大也白搭。
- 查看当前值：cat /proc/sys/fs/file-max
- 临时生效（重启失效）：sudo sysctl -w fs.file-max=2097152（200万适合8GB+内存VPS）
- 永久生效：向/etc/sysctl.conf追加fs.file-max = 2097152，再执行sudo sysctl -p
- 顺带检查fs.nr_open（单进程理论最大FD数），建议设为不低于file-max值，避免内核拒绝分配
用户级登录限制：影响服务启动时的初始FD数
很多服务（如Nginx、Redis）以普通用户身份运行，其启动时继承的是该用户的ulimit值。
- 编辑/etc/security/limits.conf，添加两行（以www-data为例）：
www-data soft nofile 65535
www-data hard nofile 65535 - 确认PAM模块已启用：检查/etc/pam.d/common-session含session required pam_limits.so，没有就加上
- 注意：修改后需重新登录用户或重启对应服务，仅改配置不重启无效
systemd服务级限制：绕过limits.conf的常见盲区
使用systemd管理的服务（现代主流发行版默认），会忽略limits.conf，必须单独配置。
- 执行sudo systemctl edit nginx（或其他服务名）
- 填入：
[Service]
LimitNOFILE=65535 - 保存后执行：sudo systemctl daemon-reload && sudo systemctl restart nginx
- 验证：cat /proc/$(cat /var/run/nginx.pid)/limits | grep "Max open files"，应显示两个65535
应用自身配置：最后一道关键适配
即使系统和systemd都设好了，某些应用仍需显式声明才能真正用满FD资源。
- Nginx：在nginx.conf的events块外添加worker_rlimit_nofile 65535;
- Java应用：启动脚本中加-XX:MaxDirectMemorySize=2g并确保JVM未主动限制FD（部分老版本有bug）
- Netty/Go服务：检查代码是否调用ulimit相关系统调用，或通过环境变量传入（如GOMEMLIMIT间接影响）
别忘了同步检查net.ipv4.ip_local_port_range——它和FD共同构成高并发网络连接的双瓶颈。如果服务大量发起主动连接（如反向代理、数据库客户端），建议扩到1024 65535，避免端口耗尽。
