服务器连接数没打满、磁盘空间也充足，但是业务查询请求全部挂掉，这类故障最常见的根因就是文件句柄先耗尽了，系统里进程打开的文件、套接字、管道都要占用句柄，句柄数量到达上限之后，进程没办法新建文件、新建 socket，哪怕网络连接、磁盘存储资源还有富余，新的查询请求也无法正常发起和处理。句柄耗尽大多是代码存在句柄泄漏，打开文件或者数据库连接之后没有正常 close 释放，或者进程默认句柄上限配置太低，业务流量上涨后快速打满阈值。排查的时候先查看进程当前句柄占用数，对比系统限制值，定位泄漏进程，接着临时调高句柄限制恢复业务，再去代码或者中间件侧补齐资源释放逻辑，后续还要增加句柄监控告警，避免同类故障复现。
一、句柄耗尽故障核心特征清单
- 资源表象：连接数指标正常、磁盘使用率正常，无磁盘满、连接溢出告警
- 业务现象：所有查询请求超时、报错，新请求无法建立
- 日志特征：大量报错提示打开文件失败、too many open files
- 故障特点：资源指标有富余，属于内核层面资源上限触发
- 恢复方式：临时调大句柄限制或者重启泄漏进程可以快速恢复
二、句柄耗尽和连接满、磁盘满故障对比
| 项目 | 句柄耗尽 | 连接数打满 | 磁盘空间满 |
|---|---|---|---|
| 核心资源 | 文件句柄 (fd) | TCP 连接 / 业务连接 | 磁盘块存储 |
| 典型报错 | too many open files | connect refused、连接池耗尽 | No space left on device |
| 资源指标 | 连接、磁盘指标正常 | 连接指标触顶 | 磁盘使用率 100% |
| 恢复手段 | 重启进程、调大 nofile | 释放闲置连接、扩容连接池 | 清理磁盘垃圾文件 |
| 排查优先级 | 容易被忽略 | 告警明显 | 告警明显 |
三、常用排查步骤
- 执行命令查看系统全局和进程级句柄上限与当前占用
- 定位占用句柄最高的业务进程，统计打开 fd 列表
- 核对业务代码：文件读取、数据库连接、http 客户端、日志句柄是否有未关闭
- 检查中间件：缓存、消息队列客户端是否存在连接句柄泄漏
- 临时修改 limits.conf 或者 ulimit 调高 nofile，快速恢复业务
- 修复代码释放逻辑，增加定时巡检，接入监控告警
四、常见造成句柄泄漏的原因
- 代码打开文件、流对象，异常分支没有执行关闭逻辑
- 第三方 SDK、客户端连接创建之后没有主动销毁
- 日志组件循环创建日志句柄，长期不回收
- 异步任务、协程批量创建 socket，异常退出没有释放
- 容器环境 ulimit 配置偏小，没有单独调高进程句柄限制
【常见问题】
问题 1：连接没满、磁盘没满，查询全挂，句柄耗尽是什么意思？
回答 1：连接没满、磁盘没满，查询全挂，句柄耗尽就是进程可用文件句柄资源用光，系统无法新建文件和套接字，哪怕连接、磁盘资源富余，新查询请求也无法正常执行。
问题 2：连接没满、磁盘没满，查询全挂，句柄耗尽该怎么快速恢复业务？
回答 2：连接没满、磁盘没满，查询全挂，句柄耗尽可以先重启发生泄漏的进程，或者临时调高 ulimit 句柄上限，优先恢复查询服务，之后再定位泄漏点根治问题。
问题 3：连接没满、磁盘没满，查询全挂，句柄耗尽怎么避免再次发生？
回答 3：连接没满、磁盘没满，查询全挂，句柄耗尽需要在代码里确保所有打开资源都关闭，调高合理句柄上限，同时增加句柄用量监控，阈值提前告警。
【参考资料】
[2026-11-08]（服务器连接磁盘正常但服务不可用，句柄泄漏排查思路）InfoQ
[2026-11-05]（Linux too many open files 故障复盘：句柄耗尽定位方案）掘金
[2026-11-02]（Linux 句柄资源原理与监控最佳实践）51CTO
【免责声明】
本文内容仅为运维故障经验整理，不构成线上生产环境直接操作规范；不同操作系统、容器环境句柄配置方式存在差异，线上操作前务必在测试环境验证，操作做好备份和回滚方案。