Linux如何排查系统句柄数超限问题 修改file-max与ulimit

遇到“Too many open files”报错，很多人的第一反应就是去调大file-max或者ulimit。但这就好比家里水管漏水，第一反应不是去找漏点，而是去把水表的总阀门拧大——水压是暂时上来了，但地板迟早要被泡坏。句柄超限问题的核心，从来不是“调大就完事”，而是要先确认三件事：系统是不是真的满了？是谁在“吃”句柄？以及，为什么它只吃不吐？否则，盲目修改参数，往往只是把系统崩溃的时间往后推迟了一天而已。

怎么看系统到底满没满

别只看报错信息就下结论。句柄限制其实有两层天花板，得分开验证：一层是整个系统的全局总量，另一层是单个进程的个体限额。

• 系统级总量：cat /proc/sys/fs/file-max 显示的是内核允许的全局上限，比如常见的1048576。但真正反映压力的，是另一个命令的输出：cat /proc/sys/fs/file-nr。它会返回三列数字，其中第二列才是当前已分配且未释放的文件描述符（fd）数量。只有当这个数字接近第一列（已分配总数）时，才说明系统级资源真的告急了。
• 进程级限额：在shell里执行ulimit -n，看到的只是当前shell会话的软限制，默认通常是1024。但实际运行的进程可能继承了一个更小的值。想知道真相，得查进程运行时真实的限制：cat /proc/$(pidof nginx)/limits | grep “Max open files”，重点看“Soft Limit”这一项到底是多少。
• 一个常见的迷惑点：用lsof -p | wc -l统计某个进程打开的fd数，发现结果远超其Soft Limit，但进程居然没报错？这通常意味着它没有通过标准的open()系统调用来打开文件（比如使用了memfd_create()这类特殊接口），或者它的限制被systemd的LimitNOFILE配置给覆盖了。

为什么改了 /etc/security/limits.conf 却不生效

这是最让人头疼的问题之一。原因很简单：大多数现代Linux发行版（尤其是使用systemd作为初始化系统的）在启动后台服务时，根本不会去读取这个经典的配置文件。

• 对于交互式登录用户：修改/etc/security/limits.conf后，你需要重新登录（开启一个新的login shell），su或者已有的ssh会话子进程是不会生效的。同时，还得确认/etc/pam.d/common-session（或类似PAM配置）中包含了session required pam_limits.so这一行。
• 对于systemd服务（比如Nginx、Redis、MySQL）：limits.conf完全无效。你必须修改对应的service unit文件。推荐的做法是创建一个override配置片段，例如在/etc/systemd/system/nginx.service.d/override.conf中写入[Service]\nLimitNOFILE=65536，然后执行systemctl daemon-reload并重启服务。
• 对于容器环境（Docker/K8s）：在宿主机上修改任何参数对容器内部都是无效的。你需要在启动容器时指定，例如docker run --ulimit nofile=65536:65536，或者在Kubernetes Pod的securityContext.fdsLimit字段中进行设置。

file-max 和 nr_open 不能乱调

把file-max调大听起来很解渴，但它并非没有代价。每个文件描述符在内核中都会占用一小块内存（大约1KB），无节制地调高会消耗宝贵的内核内存。更关键的是另一个参数：nr_open。它定义了单个进程能够申请的文件描述符硬上限。你必须保证nr_open的值大于或等于file-max，否则，你连想通过ulimit -n设置一个较大的进程限制都做不到。

• 临时调整：执行sysctl -w fs.file-max=2097152可以立即生效，但重启后会丢失。
• 永久生效：将fs.file-max=2097152写入/etc/sysctl.conf。同时，务必检查fs.nr_open的值是否足够大，可以用cat /proc/sys/fs/nr_open查看。如果不够，你需要修改内核启动参数，通常在/etc/default/grub文件的GRUB_CMDLINE_LINUX行末尾添加nr_open=2097152，然后执行update-grub并重启。
• 一个隐蔽的坑：某些云服务商的系统镜像（例如阿里云的一些CentOS镜像）默认nr_open值设置得较低（比如1048576）。如果你把file-max设为200万，修改会“静默失败”——sysctl -p命令可能不会报错，但实际上限并没有提上去。

真正该花时间的地方：定位泄漏而非调参

调整系统参数最多为你争取到几个小时的排查时间。如果不找到并修复泄漏的根源，问题迟早会卷土重来。排查时，重点关注以下几类文件描述符：

• 大量处于 CLOSE_WAIT 状态的 socket：这通常意味着你的应用程序（本端）没有主动调用close()。在Ja va中可能是Socket对象未关闭，在Node.js中可能是net.Socket没有调用destroy()。
• 一堆 anon_inode 或 eventpoll：这往往指向epoll实例泄漏。常见于C/C++自研的网络库，或者Go语言中net.Conn未正确关闭的情况。
• 重复路径的日志文件（如/var/log/app.log.1, .2, .3）：这通常是logrotate在切割日志时，程序没有正确处理SIGHUP信号重新打开日志文件，导致旧的fd一直被进程持有。检查logrotate配置是否使用了copytruncate选项，或者程序是否实现了信号处理逻辑。
• 使用统计命令快速定位：与其干巴巴地看lsof输出的几千行，不如用这个命令快速筛选高频连接目标：lsof -p | awk ‘$5 ~ /IPv|sock/ {print $9}’ | sort | uniq -c | sort -nr。它能帮你立刻看出进程在和哪个远程地址建立了大量连接。

最后，还有一个最容易被忽略的泄漏场景：子进程继承了父进程的fd。尤其是在fork()后执行exec()的程序模型中，如果父进程打开的大量连接（比如5000个socket）没有设置FD_CLOEXEC标志，那么子进程一启动就会“继承”这5000个fd，而开发者很可能完全意识不到这一点。所以，在编写会创建子进程的服务时，检查文件描述符的close-on-exec标志是否设置，是一个很好的习惯。

排查句柄泄漏的正确思路是：先分层验证系统级（/proc/sys/fs/file-nr第二列）与进程级（/proc/pid/limits）的实际使用量，定位到泄漏源，而不是盲目调整参数；对于systemd服务，需要配置LimitNOFILE；对于容器，必须在运行时指定ulimit；同时要注意file-max必须≤nr_open，否则修改可能会静默失败。