/proc/sys/fs/file-nr 输出三列：第一列为已分配fd总数（含未回收），第二列为已分配但未使用数（现代内核通常为0），第三列等于file-max即系统硬上限；关键监控指标是第一列≥第三列90%时需预警。
/proc/sys/fs/file-nr 是 Linux 内核实时暴露的系统级文件描述符（FD）使用状态快照，输出三个以空格分隔的整数，例如：12480 0 2097152。它不依赖配置缓存，无需 root 权限即可读取，是判断 FD 资源是否濒临耗尽的最直接依据。
三个数字的准确含义
从左到右依次为：
- 第一列（已分配总数）：内核当前已分配出去的文件描述符总个数，包括正在使用的、刚关闭但尚未完成回收的 FD。这是反映系统整体 FD 消耗压力的核心指标。
-
第二列（已分配但未使用数）：历史上分配过、现已释放但内核尚未彻底回收的 FD 数量。在 Linux 2.6+ 内核中，该值长期为
0属正常现象，说明 FD 回收及时；若持续大于几百（如 >1000），可能提示句柄泄漏或内核回收延迟，需结合lsof -nP | awk '{print $2}' | sort | uniq -c | sort -nr | head追查异常进程。 -
第三列（系统上限）：等于
/proc/sys/fs/file-max的当前运行值，即内核允许分配的 FD 总数硬限制。它不是配置文件里的值，也不是sysctl fs.file-max显示的缓存值，而是内核实际生效的上限。
关键监控逻辑和阈值建议
真正需要关注的是第一列与第三列的比值：
- 当
第一列 ≥ 第三列 × 0.9（即剩余不足 10%）时，系统已接近 FD 耗尽。此时新进程 fork、新网络连接 accept、甚至部分系统调用都可能失败，错误日志中会出现VFS: file-max limit XXXX reached。 - 不要依赖
ulimit -n或单个进程的/proc/[pid]/limits来缓解该问题——那是进程级限制，而file-nr反映的是全局瓶颈。 - 日常巡检可用一行命令快速预警：
awk '{used=$1; total=$3; if (used/total > 0.9) print "ALERT: FD usage", used, "/", total, sprintf("%.1f%%", used/total*100)}' /proc/sys/fs/file-nr
为什么不能只看 ulimit 或 lsof 统计
ulimit -n 仅影响当前 shell 及其子进程的软限制，对 systemd 服务、守护进程或内核线程无效；lsof -n | wc -l 统计的是用户态可见的打开文件，会漏掉内核内部使用的 FD（如 inotify 实例、eventfd、timerfd 等），且性能开销大、结果滞后。而 /proc/sys/fs/file-nr 是内核内存中的原子计数器，毫秒级更新，零误差、零开销。
关联参数协同理解
要完整把握 FD 限制体系，需同步参考：
-
/proc/sys/fs/file-max：确认第三列来源，也是调优目标值； -
/proc/sys/fs/nr_open：单进程可设ulimit -n的绝对上限（默认 1048576），若想把某进程ulimit -n设到 200 万，必须先确保nr_open ≥ 2000000； -
/proc/[pid]/limits：验证具体服务进程的 Soft/Hard Limit 是否按预期加载（尤其 systemd 服务需检查LimitNOFILE=配置是否生效）。
