Linux 文件描述符快耗尽怎么查：进程上限、监听句柄与恢复验证

Linux 服务报 too many open files 时，别上来就想着调大文件打开上限，先搞清楚到底是哪个进程在什么时间点占光了大量文件描述符。普通文件、管道、socket、监听端口都会占用描述符，只盯着磁盘剩余空间或者只改全局ulimit配置，很容易把句柄泄漏误判成默认上限太小，白忙活半天找不到根因。

先确认：报错来自哪个进程

同一台机器上跑的不同服务，文件描述符上限可能完全不一样。应用日志里的报错时间、对应进程号、部署实例信息是排查的第一手证据。如果日志只打印了报错文本，你可以先从服务管理器、进程列表或者反向代理的错误日志里定位到PID，所有后续排查都围绕这个PID来取样就行。

# 把 2468 替换成实际服务 PID
cat /proc/2468/limits | grep -i "open files"
ls -1 /proc/2468/fd | wc -l
cat /proc/sys/fs/file-nr

第一行输出进程的soft limit和hard limit，第二行是进程当前已经打开的描述符总数，第三行是系统级全局文件句柄的分配统计。这三个数字别混在一起解释：进程上限对应单进程的资源边界，系统级数值反映的是整台机器的整体资源压力。

上限够不够，不能只看一个数字

假设进程配置的上限是65535，但实际当前只打开了12000个描述符，却还是频繁报too many open files，这时候别着急改上限。有可能是短时间流量突发把句柄占满过峰值，也有可能是应用的多worker进程各自有独立的限制，单个worker先触达了阈值。反过来如果句柄占用量长期贴着soft limit涨，这时候才需要核对服务的启动配置，是不是意外沿用了非常小的默认值。

直接在终端里跑ulimit -n，查出来的只是当前shell自身的限制。那些由systemd、容器 runtime 或者其他管理组件拉起的服务，要优先查对应PID下面的/proc/PID/limits文件，再回头核对服务的启动单元配置和部署参数。这么操作可以避免“终端里明明把上限调大了，线上服务跑起来还是旧限制”的假修复问题。

按句柄类型定位泄漏还是流量峰值

文件描述符本身的编号没有诊断价值，它指向的目标对象才是排查核心。下面的小脚本只做读取和计数操作，性能开销很低，适合故障发生的窗口内针对同一个PID连续多次采样：

pid=2468
for t in 1 2 3; do
  echo "sample=$t"
  find "/proc/$pid/fd" -maxdepth 1 -type l -printf '%l\n' 2>/dev/null \
    | sed 's#^socket:\[[0-9]*\]#socket#; s#^pipe:\[[0-9]*\]#pipe#' \
    | cut -d: -f1 | sort | uniq -c | sort -nr | head
  sleep 1
done

如果socket类句柄的数量随请求量同步上涨，流量降下来之后数值也跟着回落，优先检查连接复用规则、超时配置和上游服务的响应速度。如果普通文件或者pipe类句柄的数量单调上涨，和流量高低完全没关系，基本可以判定是文件打开后没关、子进程通信句柄没回收或者日志轮转逻辑有问题。这时候别直接手动清空/proc/PID/fd下面的文件，强行关掉正在读写的句柄，很容易给正在处理的请求带来二次故障。

监听句柄与连接句柄要分开看

只知道“socket占用很多”还不够定位问题。正常服务的监听socket数量通常非常稳定，真正随流量波动的是已经建立的连接、半连接和异常关闭状态的连接。你可以把进程视角的统计和端口视角的统计放在同一个时间窗口里对比，重点观察是不是只有某一个worker进程的句柄数在持续增长。

ls -l /proc/2468/fd | grep 'socket:' | head -20
ss -s
ss -tanp | grep ':8080' | head -30

如果总连接数看起来正常，但描述符还在不停涨，问题大概率出在普通文件、管道或者重复打开的配置文件这类非连接对象上。如果连接数和描述符数同步冲高，就要把请求超时阈值、连接池上限、上游慢响应情况和keep-alive策略放到同一个时间线里交叉分析。

临时恢复与永久修复的边界

故障正在影响业务的时候，可以先踢掉无效空闲连接、平滑重启有泄漏的进程，或者确认系统整体还有余量的前提下，临时调高对应服务的soft limit。所有操作的时间点和变更的数值都要记清楚，不然故障恢复之后你根本分不清是流量下降、进程重启还是配置调整起了作用。

永久修复要对着句柄占用的类型来做：普通文件类问题补全打开后的关闭逻辑，管道类问题补全子进程回收机制，socket类问题调优超时和连接复用规则，监听端口类问题检查worker启停逻辑、避免重复创建监听句柄。单纯把上限调大只是把故障往后推迟而已，如果你每分钟采样的句柄占用斜率还是正的，说明扩容动作根本没碰着根因。

常见问题与复测方法

重启后恢复，是否就说明配置没问题？

不能。重启进程会释放这个进程持有的所有文件描述符，既可能临时清掉一波突发的连接掩盖泄漏问题，也可能只是暂时清理掉本轮累积的句柄。修复完成后要在相同量级的流量条件下连续采样，确认句柄占用量能正常回落，并且在新的上限之下保持稳定，才算临时恢复有效。

提高 open files 会不会影响其他服务？

调高单进程的文件描述符上限，不等于系统内核凭空变出更多可用资源。调整完之后还要观察系统级全局文件句柄占用、内存余量和连接跟踪的压力，给其他核心业务服务留出足够的资源余量。所有配置变更的前后都要记录进程实际生效的限制值，不要只记配置文件里写的数字。

怎样算排查闭环？

至少要留三组可以对照的采样数据：故障发生时的进程上限与句柄占用量、句柄类型分布情况、做完处理之后相同时间窗口的重复采样结果。如果句柄持续增长的趋势停止、业务报错完全消失，而且服务重载之后结果能复现保持稳定，才算完成一次可验证的完整修复。

小结

文件描述符耗尽的排查顺序可以压缩成一句话：先锁定异常进程，再核对它的运行限制和当前占用量，接着按句柄指向的目标类型做分类拆分，最后通过多次重复采样验证恢复效果。按这个流程走，既不会把shell的参数误当成线上服务的生效配置，也不会用一次简单重启把还在增长的句柄泄漏问题彻底掩盖。