增加打开文件描述符的最大数量有什么后果

Question

Ubuntu 似乎有 1024 个打开文件描述符的默认限制。Nginx 在我做的一些负载测试中抱怨已达到最大数量并且服务器基本上无法使用。

我正在测试一项服务，该服务必须每秒维持 2-3K 请求，并且每个请求都将保存到一个文件（或可能是另一个存储，如 mysql 等）。这些文件将在 x 分钟内从服务器中清除。

如果我运行 ulimit -n 并增加打开文件描述符的数量，这有什么后果？它是否使 o/s 留出更多内存来管理文件描述符，或者还有更多内存？

Answer 1

我以为一些简单的谷歌搜索会产生答案，但我受阻了。我花了一些时间查看 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 的内存。

然而，这并没有回答管理未使用的文件描述符需要多少空间的问题。我认为每个文件描述符的数量非常少，只有几个字节。

我认为将最大文件数设置为一个非常大的数字没有任何真正的缺点，最多 (2^20 from this stack overflow question。但是，如果每个打开的文件需要 1K，您显然会耗尽系统内存早在您达到该限制之前。

我的建议是继续将系统最大打开文件设置为更大的数字。如果每个打开的文件消耗大约 1K，那么 128,000 个打开的文件将仅消耗大约 128MB 的系统 RAM。在具有许多 GB 系统内存的现代系统上，这应该不是什么大问题。

免责声明：我所有这些都基于我个人的系统管理员知识和对 linux 源代码的一些非常肤浅的阅读。我不是内核黑客。