c - 如何正确处理套接字接受返回 "Too many open files"

Question

我在 tcp 端口上有一个监听套接字。进程本身使用 setrlimit(RLIMIT_NOFILE,&...); 来配置进程允许的套接字数。

对于测试，RLIMIT_NOFILE 设置为 20，当然对于生产，它将设置为更大的数字。 20 适合在测试环境中轻松达到限制。

服务器本身没有描述符泄漏之类的问题，但是试图通过增加 RLIMIT_NOFILE 来解决问题显然是行不通的，因为在现实生活中不能保证不会达到限制，无论它有多高设置。

问题是在达到限制后 accept 返回 Too many open files 并且除非文件或套接字被关闭，否则事件循环会立即开始旋转，消耗 100%一个核心。即使客户端关闭连接(例如由于超时)，服务器也会循环直到文件描述符可用于处理并关闭已经死掉的传入连接。 编辑:另一方面，客户端停止运行并且没有好的方法知道服务器是否过载。

我的问题:是否有一些标准方法可以通过在 accept 返回 Too many open files 后关闭传入连接来处理这种情况。

我想到了几种肮脏的方法:

• 关闭并重新打开监听套接字，希望所有挂起的连接都将关闭(这很脏，因为在线程服务器中，其他线程可能会获得释放的文件描述符)
• 跟踪打开的文件描述符计数(这对于具有一些未跟踪文件描述符的外部库无法正确完成)
• 检查文件描述符数量是否接近限制并在这种情况发生之前开始关闭传入连接(这是特定于实现的，虽然它可以在 Linux 上运行，但不能保证其他操作系统会在相同的情况下处理文件描述符方式)

编辑:另一种肮脏丑陋的方法:

保留一个备用 fd(例如 dup(STDIN_FILENO) 或 open("/dev/null",...))以防万一 accept 失败。顺序将是:

... accept failed
// stop threads
close(sparefd);
newconnection = accept(...);
close(newconnection);
sparefd = open("/dev/null",...);
// release threads

这种方法的主要缺点是线程同步，以防止其他线程获得刚刚释放的备用 fd。

Answer 1

您不应该使用 setrlimit 来控制您的进程可以同时处理的连接数。你的一小段套接字代码对应用程序的其余部分说，“我只想一次打开 N 个连接，这是我知道的唯一方法，所以......没有别的该过程可以有任何文件!”。如果每个人都这样做会发生什么？

做你想做的事情的正确方法很简单——跟踪你打开了多少个连接，并且在你可以处理另一个连接之前不要调用accept。