最可靠的方式是直接读取/proc/[pid]/fd目录统计实时fd数，用lsof -p pid分析类型分布，通过/proc/[pid]/limits查软硬限制，用/proc/sys/fs/file-nr监控系统级fd使用率。
监控进程打开的文件描述符数量，关键在于区分“实时精确值”和“快速概览值”，并根据场景选择轻量或深度手段。最可靠的方式始终是直接读取 /proc/[pid]/fd 目录，它不依赖权限、不经过缓存，每个数字链接就代表一个真实分配的 fd。
看单个进程的实时 fd 数量（最准）
这是排查 fd 暴涨、泄漏或“Too many open files”报错的第一步：
- 先获取目标 PID，例如：
pgrep nginx或pidof mysqld - 执行
ls -l /proc/1234/fd 2>/dev/null | wc -l（替换 1234），结果即为当前打开的 fd 总数（含 0/1/2） - 若只想统计纯数字 fd（排除 cwd、root、exe 等伪条目），用：
ls /proc/1234/fd 2>/dev/null | grep -E '^[0-9]+$' | wc -w - 配合
readlink可查具体指向：readlink /proc/1234/fd/7显示该 fd 打开的是什么资源
用 lsof 查详情与类型分布（带语义）
当需要知道“哪些文件、socket、管道占了 fd”，而不仅是数字时，lsof -p PID 不可替代：
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
- 运行
lsof -p 1234 | grep -v "can't identify protocol"避免权限干扰行 - 加
| grep REG快速聚焦普通文件（如日志、配置、临时文件） - 加
| grep "(deleted)"找出已删除但未释放的文件——它们仍占磁盘空间和 fd - 注意 FD 列：如
3u表示读写模式，1w表示只写，cwd表示当前工作目录
查进程自身的限制与软硬上限
fd 数量是否超限，不能只看用了多少，更要确认“它被允许用多少”：
- 运行
cat /proc/1234/limits | grep "Max open files"，输出两列数字分别对应 soft 和 hard limit - 这个值才是决定
open()是否失败的关键，比ulimit -n更真实（后者只对当前 shell 有效） - systemd 服务需在 unit 文件中显式配置
LimitNOFILE=65536，否则默认可能只有 1024
系统级预警：别等爆满才察觉
单个进程正常，不代表全局安全。要盯住内核级总用量：
- 执行
cat /proc/sys/fs/file-nr，关注第一列（已分配 fd 总数）与第三列（file-max）的比值 - 差值小于 5% 就该触发告警——此时新进程或连接可能直接失败
- 快速计算使用率：
awk '{printf "Usage: %.1f%\n", $1/$3*100}' /proc/sys/fs/file-nr - 避免用
lsof | wc -l统计总量：它重复计数、包含无效项，结果严重失真
