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

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 !

3 个解决方案

#1

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

您需要查看/proc/sys/fs/file-max

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

从最近的linux /文档/ sysctl / fs.txt:

file-max & file-nr:

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.

文件-max中的值表示Linux内核将分配的最大文件处理数。当您收到大量关于耗尽文件句柄的错误消息时，您可能需要增加这个限制。

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.

在历史上，文件-nr中的三个值表示已分配的文件句柄的数量、已分配但未使用的文件句柄的数量以及文件句柄的最大数量。Linux 2.6总是将0报告为*文件句柄的数量——这不是一个错误，这仅仅意味着分配的文件句柄的数量与使用的文件句柄的数量完全匹配。

Attempts to allocate more file descriptors than file-max are reported with printk, look for "VFS: file-max limit reached".

使用printk报告分配比文件max更多的文件描述符的尝试，查找“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.

编辑:潜在的错误可能不是系统耗尽全局文件描述符，而是您的进程。问题似乎是选择的最大大小限制。

#2

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

看起来您并没有达到系统文件desriptor的限制。看到这个答案。

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

也许您的服务器进程使用select，因此被限制为1024描述符?如果您切换到另一种机制，例如轮询，您将不再局限于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

FD_SETSIZE
Maximum number of file descriptors in an fd_set structure.

Try to find or output FD_SETSIZE on your system.

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

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

如果您发现FD_SETSIZE对您来说太低，我宁愿尝试从select中移开，也不愿尝试增加FD_SETSIZE，这通常比较困难。

#3

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，但是很容易增加。

#1