查某个进程实际句柄数最准方式是统计/proc/[pid]/fd/目录下符号链接数量，如ls -1 /proc/1234/fd/ 2>/dev/null | wc -l；该值即进程当前真实占用的文件描述符总数，不依赖权限、无额外开销、覆盖所有fd类型。
查某个进程实际用了多少个句柄，直接数 /proc/[pid]/fd/ 目录
最准、最快、最不依赖权限的方式就是进进程自己的 /proc/[pid]/fd/ 目录，统计里面有多少个符号链接。Linux 内核每分配一个文件描述符，就会在这个目录下建一个数字命名的软链（比如 0、1、127），所以数量就是真实占用数。
- 查自己当前 shell 进程：
ls -1 /proc/$$/fd/ 2>/dev/null | wc -l - 查 nginx 主进程（假设只有一个）：
ls -1 /proc/$(pgrep nginx | head -n1)/fd/ 2>/dev/null | wc -l - 查 PID 为 1234 的进程：
ls -1 /proc/1234/fd/ 2>/dev/null | wc -l
2>/dev/null 必须加——普通用户没权限读别人进程的 /fd/ 目录，不屏蔽错误输出会导致 wc -l 统计错乱。别用 lsof -p 1234 | wc -l，它在 fd 超过几千时容易卡住或漏数，还多一行表头。
lsof -p [pid] 只适合看具体开了哪些文件，不适合统计总数
lsof -p 输出带表头、含空行、权限失败会中断，wc -l 结果要手动减 1 才接近真实值，且无法保证覆盖所有内核 fd 类型（比如 eventfd、timerfd 在某些内核版本里不显示）。但它能告诉你每个 fd 对应什么资源：
-
FD列是描述符编号（0u= stdin,1w= stdout） -
TYPE列能看出是REG（普通文件）、IPv4（网络 socket）、CHR（字符设备）还是inotify - 如果发现大量
DEL（deleted）状态的文件，说明有句柄泄漏：文件被删了但进程没关 fd
所以它适合辅助诊断“为什么占得多”，而不是回答“到底占了多少”。
确认这个进程的上限是多少，别只看 ulimit -n
ulimit -n 显示的是当前 shell 启动该进程时继承的 soft limit，但进程可能被 systemd 或容器运行时重设过限制。真正生效的值得看它的 /proc/[pid]/limits：
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
-
cat /proc/1234/limits | grep "Max open files"输出形如：Max open files 1024 4096 files - 左边是 soft limit（运行时可调），右边是 hard limit（root 才能提）
- 如果实际用量接近 soft limit，就可能触发
Too many open files；即使系统file-max很大，单个进程也会被卡住
注意：systemd 服务必须显式配 LimitNOFILE=，否则 /etc/security/limits.conf 对它完全无效。
监控告警该盯哪列？/proc/sys/fs/file-nr 的第二列
系统级总用量不是靠加总所有进程的 fd 数来算的，而是由内核维护的全局计数器，直接读 /proc/sys/fs/file-nr 最可靠：
- 输出三列，例如：
12480 3210 2097152 - 第一列：
12480= 已分配句柄池大小（含未使用） - 第二列：
3210= 当前真正被进程持有的活跃句柄数 → 这是你写监控脚本、设告警阈值的唯一依据 - 第三列：
2097152=fs.file-max，系统允许的最大总数
别用 lsof | wc -l 去替代它——权限失败会中断，还混入表头和空行；lsof -i 更糟，只扫网络 socket，漏掉 eventfd、timerfd、普通文件等大量非网络句柄。句柄耗尽往往发生在连接密集但生命周期短的场景，这时候看 file-nr 第二列比盯着某个进程更早发现问题。
