Linux 文件描述符耗尽怎么查：ulimit、进程句柄与服务恢复

线上服务突然报“Too many open files”，重启后短时间恢复，过一会儿又复发。这个现象通常不是磁盘空间满了，而是某个进程能使用的文件描述符已经接近上限，连接、日志、管道和普通文件都在争用同一组编号。排查时要把“上限是多少”和“当前到底谁在占用”分开看，先确认目标进程，再决定调参数还是修复句柄泄漏问题。

先判断：是进程上限，还是系统资源真的不够

文件描述符可以理解为进程打开资源后拿到的一个小整数编号。TCP 连接、日志文件、匿名管道和普通文件都会占用它。达到进程限制时，常见报错是 `Too many open files`，对应的内核错误通常是 `EMFILE`；这和“磁盘满了”是两条完全不同的故障路径。

第一步先找到服务进程。假设服务名是 order-api，不要直接把 shell 里的值当成结论，先从服务状态或进程清单确认 PID：

systemctl status order-api
ps -eo pid,comm,args | grep '[o]rder-api'

记下真实 PID 后，再继续下面的检查。若服务刚刚重启过，PID 已发生变化，旧 PID 的统计就没有参考意义。

用 /proc//limits 看清软限制和硬限制

对目标进程执行：

pid=2458
grep -i 'open files' /proc/$pid/limits
ulimit -n

ulimit -n只反映当前 shell 的资源限制；服务由 systemd、容器运行时或其他父进程拉起时，二者可能完全不同。真正需要关注的是目标 PID 的 Max open files，通常会同时显示 soft 和 hard 两个值。soft 是进程当前可用的上限，hard 是普通进程能提高到的边界。

把当前打开数量也记下来：

ls /proc/$pid/fd | wc -l
cat /proc/$pid/fdinfo/* 2>/dev/null | head

如果 fd 数量已经接近 soft 值，而业务日志中同步出现连接创建失败，就可以先按“句柄耗尽”处理。这里别急着调大限制，下一步要知道句柄主要花在什么地方。

按类型统计句柄：连接、日志还是管道在增长

目录名本身就是一个快速排查信号。可以先按链接目标做粗略统计：

ls -l /proc/$pid/fd 2>/dev/null \
  | awk '{print $NF}' \
  | sed 's/.*-> //' \
  | sed 's/ .*//' \
  | sort | uniq -c | sort -nr | head

输出里如果大量出现 socket:[...]，优先检查连接池上限、空闲连接回收和异常分支是否关闭连接；如果是固定的日志路径，重点看日志轮转是否重复打开文件；如果管道和临时文件持续增长，则要检查子进程退出后的回收路径。

只看总数还不够。可以对目录内容做一个快照，隔几十秒再采集一份，对比同一类资源的占用数量是否持续增加：

find /proc/$pid/fd -maxdepth 1 -type l 2>/dev/null | wc -l
date '+%F %T'
find /proc/$pid/fd -maxdepth 1 -type l 2>/dev/null | wc -l

快照期间如果业务请求量没有明显变化，但句柄数量一直上升，泄漏的可能性就远高于“瞬时流量尖峰”的情况。记录这段变化趋势，再去查应用的连接关闭、文件流关闭和后台任务退出逻辑，比单次盲目重启更有价值。

systemd 服务怎么调整 LimitNOFILE

确认确实需要扩大文件描述符容量后，给对应服务加局部配置即可，不要直接修改系统全局文件：

sudo systemctl edit order-api

在编辑器中写入对应配置：

[Service]
LimitNOFILE=65536

保存后重新加载 unit 配置并重启服务。修改前先记录旧值和当前句柄数，后续验证恢复效果才有对照依据：

sudo systemctl daemon-reload
sudo systemctl restart order-api
systemctl show order-api -p LimitNOFILE
pid=$(systemctl show order-api -p MainPID --value)
grep -i 'open files' /proc/$pid/limits

最后两行命令返回的结果必须指向同一个新 PID，并且 `/proc/$pid/limits` 里的 soft/hard 值符合预期。只看到 unit 文件改了、却没有核对新进程的实际生效值，是这类修复操作最容易漏掉的一步。

恢复时保留一个可回退的观察窗口

如果业务已经无法接收新连接，可以先做低风险恢复：暂停流量入口或降低并发阈值，记录当前 PID、句柄数量和错误发生时间，再按服务自身的优雅重启方式恢复。不要在多个节点同时重启，否则很难判断是参数生效还是流量转移带来的临时假象。

恢复后至少核对三件事：

• 新 PID 的 `Max open files` 配置已更新，且软限制没有意外低于预期。
• 句柄数量在业务回到正常流量后趋于稳定，而不是继续单调上涨。
• 应用日志中的 `EMFILE`、连接创建失败和日志写入错误不再新增。

如果只提高限制就能让故障晚几个小时出现，说明容量确实被放大了，但根因还没解决。常见根因包括连接池没有设置上限、异常分支漏关文件句柄、日志轮转保留了旧句柄，以及子进程结束后父进程没有及时回收资源。

相关问题：文件描述符排查的三个边界

为什么我在终端里看到的 ulimit 很大，服务仍然报错？

因为 shell 和服务进程不一定拥有相同的父进程配置。以 `/proc//limits` 为准，systemd 服务则同时查看 `systemctl show` 输出的 unit 属性。

把 soft limit 调大后，hard limit 还重要吗？

这步很重要。soft limit 是当前进程的实际生效值，hard limit 是普通进程可自行提升到的最大边界；如果 hard 值本身太小，单纯修改 soft 值不会得到预期的容量。

重启服务后句柄数量归零，是否说明问题解决了？

不一定。重启会清掉旧进程持有的所有句柄，但如果新进程的句柄数量仍随时间持续增长，应该把重启视为临时缓解措施，继续定位未关闭的连接、文件或管道资源泄漏点。

收尾检查：把一次故障变成可复用的指标

建议把目标进程的句柄数量、soft limit、连接池使用率和 `EMFILE` 错误量放在同一张监控图里。真正值得关注的不是某个固定数字，而是“句柄数量 / soft limit”的增长速度，以及它和请求量、连接数之间是否同步变化。这样下一次告警到来时，可以在服务还没有完全拒绝请求前完成扩容、限流或回滚操作。