为什么在Linux中限制打开文件的数量?


136

现在,我知道如何:

  • 查找每个进程的打开文件限制: ulimit -n
  • 计算所有进程中所有打开的文件: lsof | wc -l
  • 获取允许的最大打开文件数: cat /proc/sys/fs/file-max

我的问题是:为什么Linux中的打开文件有限制?


2
@Rob用Google搜索了一下,发现它是一个叉子炸弹,它可以用来解释打开文件的限制吗?
xanpeng 2012年

6
嗯,进程限制和文件限制很重要,因此分叉炸弹之类的事情不会破坏所有用户的服务器/计算机,只会破坏做到这一点的用户,而且只能暂时破坏所有用户。否则,共享服务器上的某人可能会掀起一个前哨炸弹,并将其完全击倒给所有用户,而不仅仅是他们自己。
罗布

3
好人总结了一些非常有用的命令!:+1:
约书亚·品特2015年

7
@ Rob,fork炸弹与它没有任何关系,因为文件限制是每个进程的,并且每次您进行fork时,它都不会打开新的文件句柄。
psusi

Answers:


86

原因是操作系统需要内存来管理每个打开的文件,并且内存是有限的资源-尤其是在嵌入式系统上。

作为root用户,您可以更改每个进程(通过ulimit -n)和每个系统(例如echo 800000 > /proc/sys/fs/file-max)的最大打开文件数。


21
还有一个安全原因:如果没有限制,那么在服务器关闭之前,userland软件将能够无休止地创建文件。
Coren

15
@Coren这里讨论的限制仅适用于打开文件处理程序的数量。由于程序还可以关闭文件处理程序,因此它可以创建任意数量的文件,并可以创建所需的大小,直到所有可用磁盘空间都满为止。为防止这种情况,可以使用磁盘配额或单独的分区。从某种意义上讲,您是对的,安全性的一个方面是防止资源耗尽-为此,存在一些限制。
jofel 2012年

1
@jofel谢谢。我猜打开的文件句柄由struct file的实例表示,并且此struct的大小很小(字节级别),因此/.../file-max只要不用完内存,我可以设置一个很大的值吗?
xanpeng 2012年

7
@xanpeng我不是内核专家,但是据我所知,默认值file-max似乎是RAM大小除以10k。由于每个文件处理程序使用的实际内存应该小得多(大小struct file加上驱动程序相关的内存),因此这似乎是一个相当保守的限制。
jofel 2012年

63

请注意,lsof | wc -l总结了很多重复的条目(分叉的进程可以共享文件句柄等)。该数字可能远高于中设置的限制/proc/sys/fs/file-max

要从Linux内核的角度获取当前打开文件的数量,请执行以下操作:

cat /proc/sys/fs/file-nr

示例:尽管lsof报告的文件数量大得多,但该服务器在最多65536个打开的文件中有40096个。

# cat /proc/sys/fs/file-max
65536
# cat /proc/sys/fs/file-nr 
40096   0       65536
# lsof | wc -l
521504

1
由于lsof会报告许多文件两次或更多次,例如/dev/null,您可以尝试通过以下方式进行最佳猜测:lsof|awk '{print $9}'|sort|uniq|wc -l
Yvan

您可以lsof|awk '!a[$NF]++{c++}END{print c}'用来获取打开文件的非重复计数。
P ....

18

我认为这主要是出于历史原因。

UNIX文件描述符是一个小int值,由功能,如返回opencreat,并传递给readwriteclose,等等。

至少在Unix的早期版本中,文件描述符只是指向固定大小的每个进程结构数组的索引,其中每个结构都包含有关打开文件的信息。如果我没记错的话,一些早期的系统将这个表的大小限制为20左右。

较现代的系统具有更高的限制,但在很大程度上出于惯性而保持了相同的总体方案。


1
Solaris语言对C语言FILE数据结构的限制为20。文件句柄数始终较大。
Lothar 2014年

@Lothar:有趣。我不知道为什么限额会有所不同。鉴于filenofdopen功能,我希望它们几乎可以互换。
基思·汤普森

Unix文件不仅仅是返回的文件句柄(int)。有磁盘缓冲区和定义当前文件偏移量,文件所有者,权限,
索引

@ChuckCottrill:是的,当然。但是,无论是通过int描述符还是通过文件访问文件,大多数信息都必须存储FILE*。如果您通过打开了20个以上的文件open(),会fdopen()失败吗?
基思·汤普森
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.