美好的一天。
最近我的VPS服务器（CentOS上）开始挤压“系统中打开的文件太多”的错误。 我读了很多错误，并知道限制是由我的托pipe服务提供商设置的。 我收到主机提供商的限制列表，他们说这个限制是12000个文件。
我试图用lsof实用程序来寻找这个问题。 当问题发生时，我设法find了lsof stat的响应：
[root@XXXXXXXX]# lsof | wc -l 3895 有时达到4300左右，但我从来没有看到它跳得更高。
问题是这样的： lsof实用程序可以显示不完整的结果，还是主机的问题？ 如果它比我可以用来获得最大的数字准确性还好。
您可以使用您select的工具来监视/proc/sys/fs/file-nr ，最简单的是cat /proc/sys/fs/file-nr – 第一个数字显示分配的文件句柄，第二个分配但未使用的文件句柄，最后一个数字显示文件句柄的最大数量。
这些信息是由内核本身提供的。
重要的是您的主机如何衡量打开文件的数量。 当然/proc/sys/fs/file-nr是一个很好的候选人，所以+1。
lsof包含不包括在这个总数中的“文件”。 如果file-nr说有更多的文件句柄比lsof列表打开，我会感到惊讶。
另外要记住的是文件描述符表的大小。 每个进程都有一个FD表，但也有一个系统文件表。 您的主机可能已经做出了（每个进程的FD表）计算打开文件的（坦率地说是荒谬的）决定。 您可以将其视为每个进程的/proc/<pid>/status的FDSize字段。 它的大小必须是2的倍数，并且会增加到2的最小倍数，以保存所有打开的文件。 我们可以总结所有的FDSize条目。 再次，这将是一个不寻常的方式来衡量打开的文件，但除了快速打开许多文件，迅速增加您的使用的过程，否则我不能解释为什么他们的计数是如此之高。
我使用了一个脚本来从所有打开的进程中总结FDSize，并在两个testing系统（以root身份）上尝试了所有三个计数：
$ cat /proc/sys/fs/file-nr 544 0 12640 $ lsof | wc -l 1377 $ find /proc/ -maxdepth 1 -type d -regex '^/proc/[0-9]+$' -exec grep -Hi FDSize '{}'/status \; | cut -f 2 | awk '{total = total + $1}END{print total}' 5888 $ cat /proc/sys/fs/file-nr 8670 0 1587168 $ sudo /usr/sbin/lsof | wc -l 12309 $ find /proc/ -maxdepth 1 -type d -regex '^/proc/[0-9]+$' -exec grep -Hi FDSize '{}'/status \; | cut -f 2 | awk '{total = total + $1}END{print total}' 33088
您可以简单地询问您的主机如何衡量打开的文件。 真的FDSize是完全的废话，我无法想象他们是这样做的真实，但这是我能想到膨胀我打开的文件计数的唯一方法。