实际上，我尝试使用带有 java 的 bash 控制台在 opensuse 11 上启动 SIPP 3.3。 当我用
启动 SIPPproc = 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 终端是否有可能因为这个警告而冻结？ 如何删除此警告？
【问题讨论】：
我是 SIPp 的维护者，最近一直在研究 FD_SETSIZE 问题。
正如Increasing limit of FD_SETSIZE and select 中提到的，FD_SETSIZE 是可以传递给 select() 调用的最大文件描述符，因为它在内部使用位字段来跟踪文件描述符。 SIPp 中有代码来检查它自己的最大打开文件限制（即ulimit -n 显示的那个），如果它大于FD_SETSIZE，则按顺序将其减少到FD_SETSIZE避免 select() 出现问题。
然而，这实际上已经有一段时间没有必要了 - SIPp 使用了 poll() 而不是 select()（它没有 FD_SETSIZE 限制，并且已经被 POSIX 标准化并且自 2001 年起可移植）自 2012 年我成为维护者之前。SIPp 现在还使用 epoll，在 v3.4 版本中提供更好的性能。
我现在已经在https://github.com/SIPp/sipp 的开发代码中删除了这个FD_SETSIZE 检查，并用更明智的检查替换它 - 确保打开套接字的最大数量（加上打开调用的最大数量，每个其中可能打开自己的媒体套接字）低于文件描述符的最大数量。
【讨论】：
此警告可能与 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
【讨论】：
它的意思和它说的差不多...您的每个进程打开文件限制 (ulimit -n) 大于预定义的常量 FD_SETSIZE，即 1024。因此程序正在调整您的打开文件限制向下匹配FD_SETSIZE。
【讨论】：
FD_SETSIZE 增加到打开文件限制的数量？这样警告就不会再出现了。