Ubuntu 似乎默认限制为 1024 个打开文件描述符。在我进行的某些负载测试中，Nginx 抱怨已达到最大数量，服务器基本上无法使用。
我正在测试一项服务，该服务必须维持每秒 2-3K 个请求，并且每个请求都将保存到一个文件中（或可能是另一个存储库，如 mysql 等）。这些文件将在 x 分钟内从服务器清除。
如果我运行 ulimit -n 并增加打开文件描述符的数量，这会产生什么影响？它是否让操作系统留出更多内存来管理文件描述符，还是还有其他影响？
答案1
我以为简单的谷歌搜索就能找到答案，但我却无计可施。我花了一些时间查看 Linux 源代码，发现文件表.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）并没有什么实际缺点堆栈溢出问题)。但是，如果每个打开的文件占用 1K，则在达到该限制之前，系统内存显然就会耗尽。
我的建议是继续将系统最大打开文件数设置为更大的数字。如果每个打开文件占用大约 1K，那么 128,000 个打开文件将仅占用大约 128MB 的系统 RAM。对于具有许多 GB 系统 RAM 的现代系统来说，这应该不是什么大问题。
免责声明：我的所有这一切都基于我个人的系统管理员知识和对 Linux 源代码的一些非常肤浅的阅读。我不是内核黑客。
答案2
在 unix 类型的操作系统中，文件描述符几乎用于任何读取或写入的操作、io 设备、管道、套接字等。通常在使用 oracle 或 web 服务器时修改此限制。限制较低的原因是这些数字来自用户共享系统时。唯一真正的危害是内存不足，但通常您可以将此设置为 30k 以用于高性能服务器。