4

actually I try to start SIPP 3.3 on opensuse 11 with a bash console with java. When I start SIPP with 

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.

What does the warning means? And is it possible that the bash terminal freezes because of this warning? How can i remove this warning?

chuhx
  • 334
  • 1
  • 3
  • 14

3 Answers3

5

I'm the maintainer of SIPp and I've been looking into the FD_SETSIZE issues recently.

As is mentioned at Increasing limit of FD_SETSIZE and select, FD_SETSIZE is 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. SIPp had 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_SETSIZE in order to avoid issues with select().

However, this has actually been unnecessary for a while - SIPp has used poll() rather than select() (which doesn't have the FD_SETSIZE limit, and has been POSIX-standardised and portable since 2001) since before I became maintainer in 2012. SIPp now also uses epoll where available for even better performance, as of the v3.4 release.

I've now removed this FD_SETSIZE check 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.

Muhammad Hassaan
  • 7,296
  • 6
  • 30
  • 50
rkday
  • 1,106
  • 8
  • 12
3

This warning is supposedly related to multi-socket transport options in SIPp eg. -t un or -t tn, (though I have observed it generate these warnings even when not specifying one of these).

SIPp includes an option that controls this warning message:

   -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 SIPp attempts 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:

   -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
Muhammad Hassaan
  • 7,296
  • 6
  • 30
  • 50
John Rix
  • 6,271
  • 5
  • 40
  • 46
0

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.

twalberg
  • 59,951
  • 11
  • 89
  • 84
  • Ok, and how can I increase the `FD_SETSIZE` to the number of the open file limit? So that the warning won't appear again. – chuhx Nov 21 '13 at 07:16
  • @user3008764 [This](http://stackoverflow.com/questions/7976388/increasing-limit-of-fd-setsize-and-select) seems pertinent. – twalberg Nov 21 '13 at 12:26