bash SIPP：打开文件限制> FD_SETSIZE
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/20099751/
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
SIPP: open file limit > FD_SETSIZE
提问by chuhx
actually I try to start SIPP 3.3 on opensuse 11 with a bash console with java. When I start SIPP with
实际上，我尝试使用带有 java 的 bash 控制台在 opensuse 11 上启动 SIPP 3.3。当我开始 SIPP 时
proc = Runtime.getRuntime().exec("/bin/bash", null, wd);
...
printWriter.println("./sipp -i "+Config.IP+" -sf uac.xml "+Config.IP+":5060");
the error stream gives the following output
错误流给出以下输出
Warning: open file limit > FD_SETSIZE; limiting max. # of open files to FD_SETSIZE = 1024 Resolving remote host '137.58.120.17'... Done.
警告：打开文件限制 > FD_SETSIZE；限制最大值 # of open files to FD_SETSIZE = 1024 Resolving remote host '137.58.120.17'...完成。
What does the warning means? And is it possible that the bash terminal freezes because of this warning? How can i remove this warning?
警告是什么意思？bash 终端是否可能因为此警告而冻结？我怎样才能消除这个警告？
采纳答案by John Rix
This warning is supposedly related to multi-socket transport options in SIPpeg. -t unor -t tn, (though I have observed it generate these warnings even when not specifying one of these).
该警告可能与SIPp 中的多套接字传输选项有关，例如。-t un或-t tn,（尽管我观察到它即使没有指定其中之一也会生成这些警告）。
SIPpincludes an option that controls this warning message:
SIPp包括一个控制此警告消息的选项：
-skip_rlimit : Do not perform rlimit tuning of file descriptor limits. Default: false.
Though it has the desired effect for me of suppressing the warning output, on its own, it seems like a slightly dangerous option. Although I'm not certain of what will happen if you include this option and SIPpattempts to open more sockets than are available according to FD_SETSIZE, you may avoid possible problems on that front by also including the max_socket argument:
虽然它对我来说具有抑制警告输出的预期效果，但就其本身而言，这似乎是一个有点危险的选择。尽管我不确定如果您包含此选项并且SIPp尝试打开比根据 可用的更多的套接字会发生什么FD_SETSIZE，您可以通过还包含 max_socket 参数来避免在这方面可能出现的问题：
-max_socket : Set the max number of sockets to open simultaneously. This option is
significant if you use one socket per call. Once this limit is reached,
traffic is distributed over the sockets already opened. Default value is
50000
回答by rkday
I'm the maintainer of SIPpand I've been looking into the FD_SETSIZEissues recently.
我是SIPp的维护者，最近我一直在研究这些FD_SETSIZE问题。
As is mentioned at Increasing limit of FD_SETSIZE and select, FD_SETSIZEis the maximum file descriptor that can be passed to the select() call, as it uses a bit-field internally to keep track of file descriptors. SIPphad code in it to check its own maximum open file limit (i.e. the one shown by ulimit -n), and if it was larger than FD_SETSIZE, to reduce it to FD_SETSIZEin order to avoid issues with select().
正如在增加 FD_SETSIZE 和 select 的限制中提到的，FD_SETSIZE是可以传递给 select() 调用的最大文件描述符，因为它在内部使用位字段来跟踪文件描述符。SIPp 中有代码来检查它自己的最大打开文件限制（即 显示的那个ulimit -n），如果它大于 ，则将其FD_SETSIZE减小到FD_SETSIZE以避免 select() 出现问题。
However, this has actually been unnecessary for a while - SIPphas used poll() rather than select() (which doesn't have the FD_SETSIZElimit, and has been POSIX-standardised and portable since 2001) since before I became maintainer in 2012. SIPpnow also uses epollwhere available for even better performance, as of the v3.4 release.
然而，这实际上已经有一段时间没有必要了——在我 2012 年成为维护者之前，SIPp使用了 poll() 而不是 select()（它没有FD_SETSIZE限制，并且自 2001 年以来一直是 POSIX 标准化和可移植的）。从 v3.4 版本开始，SIPp现在还使用epoll可用的地方以获得更好的性能。
I've now removed this FD_SETSIZEcheck in the development code at https://github.com/SIPp/sipp, and replaced it with a more sensible check - making sure that the maximum number of open sockets (plus the maximum number of open calls, each of which may open its own media socket) is below the maximum number of file descriptors.
我现在已经FD_SETSIZE在https://github.com/SIPp/sipp的开发代码中删除了这个检查，并用更明智的检查替换了它 - 确保打开套接字的最大数量（加上打开调用的最大数量，每个都可以打开自己的媒体套接字）低于文件描述符的最大数量。
回答by twalberg
It means pretty much what it says... Your per-process open file limit (ulimit -n) is greater than the pre-defined constant FD_SETSIZE, which is 1024. So the program is adjusting your open file limit down to match FD_SETSIZE.
这几乎意味着它所说的......您的每个进程打开文件限制 ( ulimit -n) 大于预定义的常量FD_SETSIZE1024。因此程序正在调整您的打开文件限制以匹配FD_SETSIZE。
