fs.file-max过小会拖垮整台服务器，因其是内核级全局文件描述符硬上限，一旦耗尽，所有进程open/socket/epoll等系统调用均失败，导致ssh登录卡顿、systemd异常、nginx无法accept新连接；需通过cat /proc/sys/fs/file-nr确认是否接近阈值，并立即sysctl -w fs.file-max=1048576临时修复，再永久写入/etc/sysctl.conf及同步调整nginx worker_rlimit_nofile。
当 Nginx 出现大量 open() failed (24: Too many open files) 错误，同时服务器响应极慢、SSH 登录卡顿、甚至监控失联，很可能是 fs.file-max 被设得过小，触发内核级文件描述符耗尽，导致整个 ECS 实例陷入半瘫痪状态。
为什么 fs.file-max 过小会拖垮整台服务器？
fs.file-max 是 Linux 内核允许系统全局打开的最大文件描述符数量（包括普通文件、socket、管道、eventfd 等）。它不是单个进程的限制，而是全系统硬上限。一旦达到该值：
- 所有新进程无法成功调用
open()、socket()、epoll_create()等系统调用； - SSH 登录失败（sshd 需要创建 socket 和 session 文件）；
- systemd 服务启动/重启失败；
- Nginx 工作进程无法 accept 新连接，worker 进程频繁 crash 或 hang；
- 即使
ulimit -n设置合理，也会因内核拒绝分配而失效。
如何快速确认是 fs.file-max 导致的问题？
在还能登录的前提下，执行以下命令：
-
查当前使用量：
cat /proc/sys/fs/file-nr—— 输出三列：已分配未释放数未使用数file-max 值。若第一列接近第三列（如199876 0 200000），说明几乎耗尽； -
查历史峰值：
cat /proc/sys/fs/file-nr中第二列长期为 0，且第一列持续增长，表明文件描述符“只增不减”，常见于连接未正确关闭或泄漏； -
查 Nginx 日志：
grep "Too many open files" /var/log/nginx/error.log | tail -20，高频出现即强信号； -
对比默认值：主流 ECS（如阿里云 4C8G）默认
fs.file-max ≈ 70000~100000，若被手动改成16384或32768，极易击穿。
临时恢复 + 永久修复方法
⚠️ 注意：修改前确保有控制台 VNC 或云厂商救援模式访问能力，避免改崩后失联。
-
临时缓解（立即生效）：
sudo sysctl -w fs.file-max=1048576（推荐至少 1M）； -
永久生效：编辑
/etc/sysctl.conf，追加一行：fs.file-max = 1048576，再运行sudo sysctl -p； -
同步调整 Nginx 配置：在
nginx.conf的main块中加入：worker_rlimit_nofile 1048576;，并确保每个worker_connections×worker_processes≤ 该值； -
检查是否被云平台覆盖：部分 ECS 镜像（如某些 CentOS 官方镜像）会在
/etc/sysctl.d/下有99-cloud.conf等文件，优先级更高，需一并修改。
预防建议：不要只盯 ulimit
很多运维只调大 ulimit -n（用户级限制），却忽略内核级的 fs.file-max，这是典型盲区：
-
ulimit -n是 per-process 上限，受fs.file-max约束； - 一个 Nginx worker 进程最多打开
worker_connections个连接，但系统还需为日志文件、共享内存、定时器、第三方模块（如 lua-resty-redis）等预留空间； - 估算公式（保守）：
fs.file-max ≥ (worker_connections × worker_processes) × 2.5；例如 4 核机器配 4 个 worker、每个 1024 连接，则至少需要4 × 1024 × 2.5 ≈ 10240，但建议直接设为1048576（1M），现代服务器内存足够支撑； - 上线前用
ab或wrk压测时，同步监控cat /proc/sys/fs/file-nr，观察趋势。
