Queue length - listener configuration

[Karthik S S]

Hi,

During a performance test on a hp-ux 11.11 box, the team members are complaining that lot of requests are timing out (sockets). When I ran "netstat -p", I can see that several packets are being dropped due to full queue/listener.

7330 connect requests dropped due to full queue
768 connect requests dropped due to no listener

Also attaching the o/p of "netstat -p tcp". Are these parameters are set using ndd?? What is the recommended value for these parms? Any additional info on this is welcome.

Thanks,
Karthik S S

[Stefan Farrelly · Accepted solution]

To fix both you need to increase;

tcp_conn_request_max
(eg. ndd -set /dev/tcp tcp_conn_request_max ) Dont forget to set in /etc/rc.config.d/nddconf to make it permanent.

[Karthik S S]

Thank you Stefan. By the way what are these full queue and listeners??

-Karthik S S

[T G Manikandan]

The server is called as the listener which listens at a port and it creates a new socket for every connection from the client.

The queue mentioned here is the socket queue.

#ndd -get /dev/tcp tcp_conn_request_max
The default is 20.Increase this value.

[Stefan Farrelly]

Here is some more info on this from a restricted HP doc on network performance tuning;

tcp_conn_request_max:

Maximum number of outstanding inbound connection requests.
[1, - ] Default: 20 connections

This is also known as the maximum depth of the "listen queue." The
actual maximum for any given TCP endpoint in the LISTEN state will be
the MINIMUM of tcp_conn_request_max and the value the application
passed-in to the listen() socket call.

For this parameter to take effect for a given application, it must be
set BEFORE said application makes its call to listen(). So, if you use
ndd to set this value after the application has started, it will have
no effect unless you can get the application to recreate its LISTEN
endpoint(s).

You can see if tcp_conn_request_max MIGHT be too small by looking at
the output of either "netstat -s" or "netstat -p tcp" and looking for
the line displaying the number of connection requests dropped due to
full queue. If the number of drops is zero, the value of
tcp_conn_request_max is fine. If the value is non-zero, either
tcp_conn_request_max is too small, or the values the applications are
using in their calls to listen() are too small.