Linux中文件描述符的上限
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/12970853/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Upper limit of file descriptor in Linux
提问by nebi
what is the upper limit of file-descriptor that can be used in any Linux system (specifically ubuntu 10.04)?
可以在任何 Linux 系统（特别是 ubuntu 10.04）中使用的文件描述符的上限是多少？
I am using Ubuntu 10.04 (64-bit) and my CPU architecture for server is x86_64 and for client it is i686. Right now I had increased my fd-limit to 400000.
我使用的是 Ubuntu 10.04（64 位），我的服务器 CPU 架构是 x86_64，客户端是 i686。现在我已将 fd-limit 增加到 400000。
- What can be the possible side-effects of using large no. of file descriptors?
- How can I know about the no. file-descriptor that is used by any process?
- 使用大编号可能产生的副作用是什么？文件描述符？
- 我怎么知道没有。任何进程使用的文件描述符？
Thnx
谢谢
回答by askmish
You want to look at /proc/sys/fs/file-max instead.
您想查看 /proc/sys/fs/file-max 。
From the recent linux/Documentation/sysctl/fs.txt:
来自最近的 linux/Documentation/sysctl/fs.txt：
file-max and file-nr:
The kernel allocates file handles dynamically, but as yet it doesn't free them again.
The value in file-max denotes the maximum number of file- handles that the Linux kernel will allocate. When you get lots of error messages about running out of file handles, you might want to increase this limit.
Historically, the three values in file-nr denoted the number of allocated file handles, the number of allocated but unused file handles, and the maximum number of file handles. Linux 2.6 always reports 0 as the number of free file handles -- this is not an error, it just means that the number of allocated file handles exactly matches the number of used file handles.
Attempts to allocate more file descriptors than file-max are reported with printk, look for "VFS: file-max limit reached".
file-max 和 file-nr：
内核动态地分配文件句柄，但还没有再次释放它们。
file-max 中的值表示 Linux 内核将分配的最大文件句柄数。当您收到大量有关耗尽文件句柄的错误消息时，您可能希望增加此限制。
历史上，file-nr 中的三个值表示已分配的文件句柄数、已分配但未使用的文件句柄数和最大文件句柄数。Linux 2.6 总是报告 0 作为空闲文件句柄的数量——这不是错误，它只是意味着分配的文件句柄数量与使用的文件句柄数量完全匹配。
尝试分配比 file-max 多的文件描述符会用 printk 报告，查找“VFS：达到文件最大限制”。
The 2.6 kernel uses a rule of thumb to set file-maxbased on the amount of memory in the system. A snippet from fs/file_table.cin the 2.6 kernel:
2.6 内核使用经验法则file-max根据系统中的内存量进行设置。来自fs/file_table.c2.6 内核的片段：
/*
* One file with associated inode and dcache is very roughly 1K.
* Per default don't use more than 10% of our memory for files.
*/
n = (mempages * (PAGE_SIZE / 1024)) / 10;
files_stat.max_files = max_t(unsigned long, n, NR_FILE);
The files_stat.max_filesis the setting of fs.file-max. This ends up being about 100 for every 1MB of ram.(10%)
这files_stat.max_files是 的设置fs.file-max。对于每 1MB 内存，最终大约为 100。（10%）
回答by janneb
Each file descriptor takes up some kernel memory, so at some point you'll exhaust it. That being said, up to a hundred thousand file descriptors are not unheard of for server deployments where event-based (epoll on Linux) server architectures are used. So 400k is not completely unreasonable.
每个文件描述符占用一些内核内存，所以在某些时候你会耗尽它。话虽如此，对于使用基于事件（Linux 上的 epoll）服务器架构的服务器部署，多达十万个文件描述符并非闻所未闻。所以400k也不是完全不合理。
For the second questions, see /proc/PID/fd/ or /proc/PID/fdinfo directories.
对于第二个问题，请参阅 /proc/PID/fd/ 或 /proc/PID/fdinfo 目录。
