Linux /proc/sys/fs/file-max 与 /proc/sys/fs/nr_open 的文件描述符上限调优

file-max 是系统级文件描述符总数上限，不直接限制单进程；单进程上限由 nr_open 和 ulimit -n 共同决定，且 ulimit 受 nr_open 硬性约束。

file-max 是系统级硬上限，但不直接限制单进程

很多运维同学看到 cat /proc/sys/fs/file-max 返回 8388608 就以为“系统最多开 800 万文件”，结果单个进程 open() 到 1024 就报 Too many open files——这说明搞混了层级。file-max 是内核允许分配的**所有文件描述符总数**，类似内存总量；而单进程能用多少，由 nr_open 和用户级 ulimit -n 共同掐着。

实操建议：

• file-max 应设为预期峰值总连接数 × 1.2～1.5（比如 nginx + redis + Java 应用合计可能开 50 万 fd，则设为 60 万～75 万）
• 改完需执行 sysctl -p 生效，否则重启才生效
• 注意：该值不能高于 nr_open，否则内核启动时会自动截断到 nr_open 值

nr_open 决定 ulimit -n 的理论天花板

nr_open 是内核编译期或运行时设定的**单进程可申请 fd 数的绝对上限**。它不像 file-max 那样可随意调高——超过它，连 ulimit -n 1048576 都会被拒绝，提示 Operation not permitted。

常见错误现象：

• 执行 ulimit -n 1048576 后查仍是 1024 或 65536
• Java 进程 -XX:+UseG1GC 下大量 socket 超时，日志里反复出现 java.io.IOException: Too many open files

实操建议：

• 先看当前值：cat /proc/sys/fs/nr_open（常见默认值是 1048576）
• 若要支持单进程百万级 fd，需先调高 nr_open（如设为 2097152），再调 ulimit -n
• 修改方式：写入 /proc/sys/fs/nr_open（临时）或在 /etc/sysctl.conf 加 fs.nr_open = 2097152（永久）
• ⚠️ 注意：该值一旦写死，普通用户无法通过 ulimit 超过它；root 也不行——这是内核硬边界

ulimit -n 的实际生效受三重约束

你以为 ulimit -n 1048576 就万事大吉？不一定。它必须同时满足：nr_open ≥ 设置值 ≥ 当前 soft limit，且 shell 启动时未被父进程继承更低限制。

使用场景：

• systemd 服务中 fd 不足，LimitNOFILE 设再高也无效——因为 systemd 自己的 ulimit 受 nr_open 限制
• 容器内 ulimit -n 失效，本质是容器 runtime（如 runc）启动时从宿主机继承了受限的 limits

实操建议：

• 检查当前生效值：ulimit -n（soft）、ulimit -Hn（hard）
• 临时提限：先 ulimit -Hn 1048576，再 ulimit -Sn 1048576
• 长期生效：在 /etc/security/limits.conf 加 * soft nofile 1048576 和 * hard nofile 1048576，并确认 PAM 模块已启用 pam_limits.so
• systemd 用户服务需额外设置 DefaultLimitNOFILE=1048576 并重启 systemd --user

调完不验证等于没调

改完 file-max、nr_open、ulimit，很多人就去盯业务日志，结果几天后又爆 Too many open files——大概率是某个环节漏了验证，或者进程根本没加载新限制。

关键验证点：

• 确认进程实际 limit：cat /proc/<pid>/limits | grep "Max open files"</pid>，看 Soft Limit 和 Hard Limit 是否符合预期
• 确认 file-max 已生效：sysctl fs.file-max，别只信 cat /proc/sys/fs/file-max（可能缓存）
• 检查是否被 cgroup 限制：容器或 systemd service 下，cat /proc/<pid>/cgroup</pid> 若含 memory 或 pids controller，还需查对应 cgroup 的 tasks 和 fd 目录
• 注意：某些 Go 程序（尤其旧版）会绕过 ulimit 自行调 setrlimit(RLIMIT_NOFILE)，此时得看代码里是否硬编码了 65536

最常被忽略的是：改完 nr_open 后没重启相关服务，老进程仍卡在旧限制里。不是所有服务都支持热 reload fd 限制。