SIPP:打开文件限制 > FD_SETSIZE

4

实际上,我正在尝试在使用Java的Bash控制台上启动SIPP 3.3,并运行于opensuse 11上。 当我使用以下命令启动SIPP时:

proc = Runtime.getRuntime().exec("/bin/bash", null, wd);

... 

printWriter.println("./sipp -i "+Config.IP+" -sf uac.xml "+Config.IP+":5060");

错误流输出如下:

警告:打开文件限制>FD_SETSIZE;将最大打开文件数限制为FD_SETSIZE = 1024 解析远程主机'137.58.120.17'...完成。

这个警告是什么意思?Bash终端会因为这个警告而冻结吗? 如何消除这个警告?
3个回答

5
我是的维护者,最近一直在研究FD_SETSIZE问题。
正如所提到的在增加FD_SETSIZE和select的限制中,FD_SETSIZE是可以传递给select()调用的最大文件描述符,因为它在内部使用位域来跟踪文件描述符。中有代码来检查其自己的最大打开文件限制(即通过ulimit -n显示的那个),如果它比FD_SETSIZE更大,则将其减小到FD_SETSIZE,以避免与select()发生冲突。
然而,这实际上已经不再必要了-自从我在2012年成为维护者以来,就使用poll()而不是select()(它没有FD_SETSIZE限制,并且自2001年以来一直被POSIX标准化并且具有可移植性)。 现在还使用epoll(如v3.4版本所示)进行更好的性能。
我现在已经在https://github.com/SIPp/sipp的开发代码中删除了这个FD_SETSIZE检查,并用一个更明智的检查替换它-确保打开的套接字的最大数量(加上每个呼叫打开自己的媒体套接字的最大数量)低于文件描述符的最大数量。

3

这个警告据说与 SIPp 中的多套接字传输选项有关,例如 -t un-t tn, (尽管我已经观察到即使没有指定这些选项,它也会生成这些警告)。

SIPp 包含一个控制此警告消息的选项:

   -skip_rlimit     : Do not perform rlimit tuning of file descriptor limits.  Default: false.

虽然这个选项对我来说起到了压制警告输出的作用,但单独使用它似乎有些危险。虽然我不确定如果你包含此选项并且 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

0

这基本上意味着... 您的每个进程打开文件限制(ulimit -n)大于预定义常量FD_SETSIZE,即1024。因此,程序正在调整您的打开文件限制以匹配FD_SETSIZE


好的,我该如何将 FD_SETSIZE 增加到打开文件限制的数量?这样警告就不会再出现了。 - chuhx
@user3008764 这个链接似乎很相关。 - twalberg

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接