Linux 服务器上，很多“服务还能跑，但新文件写不进去”的问题，最后都和打开文件过多有关。它不一定表现为磁盘满，也不一定马上把 CPU 打高，更常见的现象是：Nginx 偶发 502、PHP-FPM 报错、数据库连接失败、日志无法继续写入，或者某个进程突然提示 Too many open files。对新手来说，这类故障很容易被误判成程序 bug。
什么是文件描述符
文件描述符可以简单理解为进程访问系统资源时拿到的“句柄”。在 Linux 里，不只是普通文件会占用它，网络连接、Socket、管道、日志文件、动态库、临时文件等都可能占用文件描述符。一个 Web 服务同时处理大量请求时，每个连接、每个上游转发、每个日志写入动作，都可能增加描述符使用量。
系统为了防止单个进程无限占用资源，会给进程设置打开文件数量上限。这个上限太低时，业务访问量一上来，服务就可能先撞到描述符限制；上限太高但程序存在泄漏时，又可能把系统整体资源拖垮。因此排查时既要看限制，也要看真实使用量。
常见故障表现
文件描述符耗尽最典型的报错是 Too many open files。它可能出现在 Nginx error.log、PHP-FPM 日志、Java 应用日志、数据库日志，也可能只在 systemd journal 里留下几行提示。还有一些间接表现，例如页面偶发打不开、静态资源加载失败、接口请求超时、反向代理到后端时出现 connection reset 或 connect failed。
如果服务器上部署了多个站点，某一个站点访问量突增、爬虫异常抓取、日志切割异常或程序没有正确关闭连接，都可能让相关进程的描述符数量持续升高。对于中小业务，使用 速维云云服务器 这类标准化环境时，也不要只关注 CPU、内存和带宽，进程资源限制同样需要纳入基础巡检。
先看系统整体使用量
排查时可以先看系统级文件描述符使用情况。常用命令是 cat /proc/sys/fs/file-nr，输出通常包含已分配数量、未使用数量和系统最大值。不同内核版本显示含义略有差异，但核心思路是看当前使用量是否接近系统上限。
系统最大值可以通过 cat /proc/sys/fs/file-max 查看。如果整体数值已经接近上限，说明问题不只是某个服务的小限制，而是整个系统资源可能被大量连接或异常进程消耗。此时不要急着单纯调大参数，应先找出是谁占用了大量描述符。
定位哪个进程占用最多
最直接的方法是查看进程打开了多少文件。可以用 ls /proc/进程ID/fd | wc -l 查看单个进程，也可以配合 lsof 做统计。例如先用 ps aux 找到 Nginx、PHP-FPM、MySQL、Java 等关键进程的 PID，再逐个检查 fd 数量。
如果服务器安装了 lsof，可以使用类似 lsof -n | awk '{print $2}' | sort | uniq -c | sort -nr | head 的思路找出打开文件最多的进程。看到某个 PID 明显高于其他进程后，再用 lsof -p PID | head 或按类型筛选，判断它打开的是日志文件、网络连接、临时文件还是大量重复资源。
检查当前限制
进程限制通常来自多个层级：Shell 的 ulimit -n、systemd 服务配置里的 LimitNOFILE、应用自身配置，以及系统内核参数。很多人只在终端里执行 ulimit -n 65535，但服务是由 systemd 启动的，这种临时修改对已经运行的服务并不会生效。
如果是 systemd 管理的服务，可以用 systemctl show nginx -p LimitNOFILE 这类命令查看限制。需要调整时，通常建议用 drop-in 配置，例如 systemctl edit nginx，写入 [Service] 和 LimitNOFILE=65535，再执行 daemon-reload 和重启服务。生产环境调整前要评估业务窗口，避免误重启影响访问。
不要只调大上限
调大文件描述符上限可以缓解压力，但它不是万能解法。如果程序存在连接泄漏、日志句柄不释放、短连接异常堆积，单纯把上限从 1024 改到 65535，只是把故障时间往后推。真正可靠的处理方式，是同时确认连接来源、请求模式、应用日志和代码行为。
例如 Web 站点突然出现大量 ESTABLISHED 或 CLOSE_WAIT 连接，就要进一步检查上游应用是否及时关闭连接、客户端是否异常、反向代理超时设置是否合理。数据库连接池也类似，如果连接池配置过大或回收异常，可能同时引发数据库连接数和文件描述符压力。
日常巡检建议
对线上服务器来说，文件描述符适合纳入基础监控。至少应关注系统已用描述符数量、关键服务进程 fd 数量、Nginx/PHP-FPM/数据库错误日志，以及连接状态变化。如果短时间内 fd 数量持续上升且不回落，就要警惕泄漏或异常访问。
中小团队可以把这类检查写进日常运维手册：先看报错，再看系统整体，再定位进程，然后检查限制与连接来源。这样遇到 Too many open files 时，就不会只凭经验重启服务。重启可能暂时恢复访问，但如果根因没有处理，下一次流量高峰仍然会再次出现。
总结
文件描述符耗尽，本质上是“进程能同时打开的资源数量不够或被异常占满”。它和磁盘空间、内存、连接数、日志写入都有交叉关系，因此排查时要按层次推进：系统上限、进程占用、服务限制、连接状态、应用行为，一个都不能少。
如果你在维护网站、接口服务或数据库服务，建议提前记录关键服务的正常 fd 范围。只有知道平时是多少，故障时的异常增长才更容易被发现。稳定的运维不是等报错再救火，而是在资源快到边界前就能看见趋势。
