fs.nr_open是单进程文件描述符硬上限，决定ulimit -n最高可设值；fs.file-max是全系统总句柄数上限，二者作用域不同，必须协同调整且满足fs.file-max≤fs.nr_open。
fs.nr_open 和 fs.file-max 都管“文件打开数”，但作用层级完全不同：前者是单个进程能申请的文件描述符（fd）绝对上限，后者是整个系统所有进程加起来能用的 fd 总量。
fs.nr_open：单进程硬边界，不可绕过
这是内核设定的每个进程最多能打开多少 fd 的“天花板”。它不是建议值，而是硬性拦截——哪怕 root 用户执行 ulimit -n 2097152，只要该值超过当前 nr_open，命令就会失败并提示 Operation not permitted。
- 默认常见值为 1048576（100 万），查看命令：
cat /proc/sys/fs/nr_open - 若需支持单进程百万级以上 fd（如高并发网关、大数据处理进程），必须先调高此值，例如设为 2097152
- 修改方式（永久）：
echo "fs.nr_open = 2097152" >> /etc/sysctl.conf && sysctl -p - ⚠️ 注意：该值一旦生效，普通用户和 root 都无法通过 ulimit 超越它；它是编译期/运行时内核强约束
fs.file-max：系统总容量，需协同 nr_open
它代表内核允许分配的全部文件描述符总数，类似“系统级内存总量”。但它不直接限制单个进程——哪怕 file-max 是 200 万，如果 nr_open 只有 100 万，那单个进程最多仍只能开 100 万 fd，且所有进程加起来也不能突破 200 万。
- 查看当前生效值：
cat /proc/sys/fs/file-max（注意：不要只信sysctl fs.file-max，某些发行版缓存不准） - 合理取值参考：按峰值总连接数 × 1.2～1.5 估算。例如 Nginx + Java + Redis 预估共需 60 万 fd，则设为 72 万～90 万
- 必须满足：
fs.file-max ≤ fs.nr_open，否则内核启动时会自动截断到nr_open值，配置实际无效 - 监控关键指标：
cat /proc/sys/fs/file-nr返回三列，如12480 0 2097152，第一列是已用总数，第三列是上限；差值小于 10% 就要预警
为什么常一起调？因为它们是上下级依赖关系
很多服务报 Too many open files 并非只缺一个参数。比如 Java 应用开启大量 socket 和日志文件，既可能单进程超限（nr_open 不够），也可能全系统耗尽（file-max 不足），还可能被用户级 ulimit -n 卡住。
- 典型组合示例（生产推荐）：
fs.nr_open = 2097152fs.file-max = 2097152
（再配合/etc/security/limits.d/90-nofile.conf中* soft nofile 1048576和* hard nofile 2097152） - 调优顺序建议：先确认应用预期最大 fd 数 → 设定
nr_open→ 再按并发进程数 × 单进程平均 fd → 设定file-max→ 最后配用户级 limits - 验证是否生效：改完运行
sysctl -p，再分别检查/proc/sys/fs/nr_open和/proc/sys/fs/file-max输出是否匹配
顺带提两个 inotify 相关参数（常被忽略但影响大）
IDE、热重载、文件同步等场景容易触发 No space left on device（磁盘明明有空余），本质是 inotify 资源耗尽，和 fd 无关但同属 fs.* 空间：
-
fs.inotify.max_user_watches：单用户可监听的文件/目录总数，默认仅 8192，建议至少 524288 -
fs.inotify.max_user_instances：单用户最多创建多少 inotify 实例，默认 128，频繁启停监听器时建议设为 1024 或更高 - 它们也需写入
/etc/sysctl.conf并sysctl -p生效，且修改后无需重启服务
