凌晨两点，线上服务的文件描述符（FD）越过告警线，老连接仍能响应，新登录却开始超时。重启单个进程后曲线短暂回落，几分钟后再次爬升，这不是一次抖动：真正要查的是谁没有释放句柄、连接只是堆积，还是整机资源已经逼近耗尽。
如果你正在选机器，或者想先把线路和配置跑通再谈长期方案，可以先看看这几家的线路说明和技术参数：dogyun（低价云服务器），先看清带宽线路、流量策略和退款条款，再决定要不要迁。
一、句柄水位上涨不等于文件泄漏
每个进程都受文件描述符上限约束，常见值是1024或65535，但两者都不能代表整机余量。持续观察 /proc/PID/fd 的数量，才能判断进程内部是否存在单调增长；若连接数平稳而FD同步上涨，才更像应用没有关闭资源。
打开文件分类比总数更有价值：套接字指向网络连接，匿名inode常对应事件通知、进程间通信或定时器，普通文件则包括日志、配置和缓存。仅凭FD总数容易误判，应结合 lsof、目标路径及socket状态继续归类。
连接堆积通常伴随大量ESTABLISHED或CLOSE_WAIT，释放连接后计数会下降；应用未释放则常见已删除文件、匿名句柄持续增加。系统级耗尽则表现为文件描述符水位接近系统上限、文件分配失败增加，并可能伴随内存压力。
二、从进程曲线追到具体泄漏源
先按30至60秒采样各进程的FD数量、打开文件分类和连接状态，再用 /proc/PID/limits 核对“Max open files”。只在总量层面观察，会被多进程模型、共享描述符和容器PID命名空间干扰；句柄泄漏溯源必须关联进程、线程和时间序列。
若单个工作进程的FD持续增长，可检查socket、pipe、eventfd及已删除文件；若FD在请求结束后不回落，重点审查异常分支、连接池和响应体关闭。若多个进程同时触顶，再检查系统文件余量、cgroup限制以及宿主机层面的进程资源隔离配置。
常见踩坑包括误把高并发当成泄漏、看到删除文件便直接清空目录，以及盲目调高ulimit。止损应先停止无意义重试、关闭空闲或僵死连接，并保留现场快照；确认单个进程异常后再滚动回收。后续的限额与回收策略应基于真实峰值制定，而非用无限扩容掩盖问题。快照可暂存于随身服务器，便于对比故障前后的变化。
从水位异常完成句柄泄漏溯源
文件描述符水位异常，并不等于句柄泄漏。连接池长连接、正在写入的日志、队列消费者都可能合理占用句柄；真正的泄漏通常表现为重启前数量只升不降、单位时间新增速率抬高，且多数描述符已无业务价值。排查要同时记录基线水位、增长速度、进程启动时间与业务负载，不能只看瞬时总数。
先查 /proc/PID/limits 中的 open files 限额，再用 ls -l /proc/PID/fd 与 lsof -p PID 对照；readlink /proc/PID/fd/* 可查看目标，/proc/PID/fdinfo/FD 可补充标志位。按打开文件分类统计普通文件、目录、管道、套接字、匿名 inode 和设备节点。出现 (deleted) 不能直接判定泄漏，日志轮转也会产生这种状态。
最容易踩的坑是只查总量，不查句柄归属。描述符可能被 fork 后继承，父子进程会各显示一次；父进程未关闭共享记录，子进程退出也不会释放它。采样时目标恰好被关闭会产生 ENOENT，通常不是异常。还要区分“正在使用”与“无人管理”：前者看连接池指标和读写耗时，后者才回溯到未关闭的流、监听器或异常分支。
用隔离、限额与回收控制复发
修复时先关闭明确的泄漏点，再设置合理的 RLIMIT_NOFILE 软限和硬限；systemd 服务可用 LimitNOFILE= 固化上限，并给配置、日志和运行时加载预留余量。cgroup 内存配额不会自动限制打开文件数，不能替代句柄配额。上限应高于正常峰值，否则进程会报 EMFILE 或 ENFILE，扩大故障。
进程资源隔离方面，把 Web Worker、代理和消息代理拆成独立服务，配置启动次数、内存与队列上限，避免单点拖垮全局。限额与回收策略应优先采用请求超时、连接空闲回收、句柄池容量上限和滚动重启；旧进程先摘流并排空请求。不要盲目杀线程或删除 /proc 链接，这不能安全关闭内核引用，还可能破坏在途请求。
最终检查清单：①记录正常负载下的 FD 基线、峰值和增长率；②确认软硬限额匹配业务模型；③按文件、套接字、管道等分类；④核对父子继承、连接池与日志轮转；⑤修复无业务引用的关闭路径；⑥补充超时、池容量和空闲回收；⑦灰度验证 FD 曲线能够回落；⑧配置分级告警、摘流及回滚方案。
喜欢 
顶
难过
囧
围观
无聊
