Ubuntu似乎有1024个打开的文件描述符的默认限制。 Nginx正在抱怨一些负载testing，我正在做的最大数量已经达到和服务器基本上是无法使用的。
我正在testing一个服务，将不得不维持每秒2-3K的请求，并且每个请求将被保存到一个文件（或潜在的另一个存储如mysql等）。这些文件将在服务器x分钟内被清除。
如果我运行ulimit -n并增加打开的文件描述符的数量，这会产生什么影响？ 它是否使得o / s留出更多的内存来pipe理文件描述符，还是有更多的内存？
我认为一些简单的Googlesearch会产生一个答案，但我被挫败了。 我花了一些时间看着linux源代码，发现file_table.c 。 该源文件底部的files_init是打开的文件表被初始化的地方，它有这样的注释：
/* * One file with associated inode and dcache is very roughly 1K. * Per default don't use more than 10% of our memory for files. */ 该函数中的逻辑将系统max_files设置为请求的最大值（NR_FILES）或系统内存的10％中的较大者。 显然每个打开的文件都会消耗大约1K的内存。
但是，这并没有回答pipe理未使用的文件描述符需要多less空间的问题。 我认为这是一个非常小的每个文件描述符，只有几个字节。
我认为将最大文件数量设置为一个非常大的数目是没有任何实际的缺点的，从这个堆栈溢出问题可以达到（2 ^ 20），但是如果每个打开的文件占用1K，那么显然将会用完系统内存很久以前，你达到了这个限制。
我的build议是继续前进，并设置您的系统最大打开文件到一个更大的数字。 如果每个打开的文件消耗大约1K，那么128000个打开的文件将只消耗大约128MB的系统RAM。 对于具有许多系统RAM的现代系统，这应该不是什么大问题。
免责声明：我将所有这一切都基于我的个人系统pipe理员知识和一些非常肤浅的Linux源代码阅读。 我不是内核黑客。
在unixtypes的操作系统中，文件描述符几乎用于读写任何东西，IO设备，pipe道，套接字等等。通常在使用oracle或web服务器时修改这个限制。 限制的原因是因为这些数字来自用户共享系统的时间。 唯一真正的危害是如果你的内存量很less，但是通常你可以把它设置为30k，用于高性能的服务器。