linux文件描述符限制如何工作？

How do linux file descriptor limits work?

提问by erotsppa

I was told that my server refused to accept client network connections at a specific port could be due to the lack of file descriptors. I looked up what this is all about and read about it here: http://www.netadmintools.com/art295.html

有人告诉我，我的服务器拒绝在特定端口接受客户端网络连接可能是由于缺少文件描述符。我查了一下这一切，并在这里阅读：http: //www.netadmintools.com/art295.html

So I tested my system and I got this:

所以我测试了我的系统，我得到了这个：

cat /proc/sys/fs/file-nr
1088    0   331287

What does this mean? My limit is quite high yet I have 0 available file descriptors? why? How do I solve this for my server?

这是什么意思？我的限制很高，但我有 0 个可用的文件描述符？为什么？我如何为我的服务器解决这个问题？

The second column actually stays at 0 even after I shutdown my server, it even stays at 0 even right after a boot!

即使在我关闭服务器后，第二列实际上仍保持在 0，即使在启动后它甚至保持在 0！

采纳答案by wnoise

You want to look at /proc/sys/fs/file-max instead

您想查看 /proc/sys/fs/file-max

From recent linux/Documentation/sysctl/fs.txt:

来自最近的 linux/Documentation/sysctl/fs.txt：

file-max & 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 中的值表示 Linux 内核将分配的最大文件句柄数。当您收到大量有关耗尽文件句柄的错误消息时，您可能希望增加此限制。

历史上，file-nr 中的三个值表示已分配的文件句柄数、已分配但未使用的文件句柄数和最大文件句柄数。Linux 2.6 总是报告 0 作为空闲文件句柄的数量——这不是错误，它只是意味着分配的文件句柄数量与使用的文件句柄数量完全匹配。

尝试分配比 file-max 多的文件描述符会用 printk 报告，查找“VFS：达到文件最大限制”。

EDIT: the underlying error is probably not the system running out of global filedescriptors, but just your process. It seems likely that the the problem is the maximum size limit of select.

编辑：潜在的错误可能不是系统用完全局文件描述符，而只是您的进程。问题似乎是select的最大大小限制。

回答by Peter G.

It does not look like you are hitting the system file desriptor limit. See this answer.

看起来您没有达到系统文件描述符限制。看到这个答案。

Perhaps your server process uses selectand is thus limited to 1024 descriptors? If you switch to another mechanism, e.g. pollyou will not be limited to 1024 descriptors anymore.

也许您的服务器进程使用select并因此被限制为 1024 个描述符？如果您切换到另一种机制，例如，poll您将不再局限于 1024 个描述符。

select()works with fd_sets

select()与fd_sets 一起工作

This is from the POSIX documentation of select.h:

这是来自 select.h 的 POSIX 文档：

The following shall be defined as a macro:

FD_SETSIZE

Maximum number of file descriptors in an fd_set structure.

以下应定义为宏：

FD_SETSIZE

Maximum number of file descriptors in an fd_set structure.

Try to find or output FD_SETSIZEon your system.

尝试FD_SETSIZE在您的系统上查找或输出。

If you find FD_SETSIZE is too low for you, I would rather try to move away from selectthan trying to increase FD_SETSIZEwhich is typically harder.

如果您发现 FD_SETSIZE 对您来说太低，我宁愿尝试远离而select不是尝试增加FD_SETSIZE这通常更难。

回答by MarkR

What error are you getting from accept() under these circumstances? Check errno and report it accordingly.

在这些情况下，你从 accept() 得到什么错误？检查 errno 并相应地报告它。

According to the man page, accept() will give EMFILE or ENFILE if the per-process or overall file descriptor limit has been reached, it would be helpful to know which (or if there was something else).

根据手册页，如果已达到每个进程或整体文件描述符限制，accept() 将给出 EMFILE 或 ENFILE，了解哪个（或是否还有其他内容）会很有帮助。

There is a per-process file descriptor limit which is often set to 1024 - but can easily be increased.

每个进程的文件描述符限制通常设置为 1024 - 但很容易增加。