TCPIP connection problem

[Pierre Starmans]

We use a central HP-UX server (version 11.11) as saprouter-server to provide OSS connections for authorized SAP R/3 systems.
Connections are established via TCP service 3299 (/etc/services).

Sometimes we face a limitation problem; no additional connections can be set up. After another connection is closed, a new one can be opened.

Couls this be a TCP limitation; I was thinking maybe of parameter tcp_conn_request_max

Thanks in advance for your reaction

[Todd Whitcher]

Hello,

Check the output of "netstat -p -tcp" and look for the value of Connection Requests dropped due to full queue if thats zero then you should not have to tune tcp_conn_request_max.

The default is 20 on 11.i, a good value to test w/ is 1024. Remember to also make your change in the /etc/rc.config.d/nddconf file.


Usable commands:
Check the current value:

ndd -get /dev/tcp tcp_conn_request_max
Set the maximum for the connection request to 1024:

ndd -set /dev/tcp tcp_conn_request_max 1024


nddconf entry example:
TRANSPORT_NAME[0]=tcp
NDD_NAME[0]=tcp_conn_request_max
NDD_VALUE[0]=1024

[Claudio Cilloni]

This isn't surely a TCP limitation. If that service runs through inetd deamon try search in the inetd configuration, or in the OSS server configuration.
How much connection can you have together?

Ciao
Claudio

[Ron Kinner]

tcp_conn_request_max is just the limit on the number of new connections that can try to get set up at once. They get stuck in a queue and have to wait until they are handled. This parameter is the queue length. It doesn't sound like it would be your problem and I'm not convinced that a nonzero indication would necessarily indicate a problem with tcp_conn_request_max since per HP's Rick Jones at:

ftp://ftp.cup.hp.com/dist/networking/briefs/annotated_netstat.txt

there is another reason which might cause this:

"0 connect requests dropped due to full queue

If the number of connection requests (SYN segments) dropped due to
full queue is non-zero it means that either the setting for
tcp_conn_request_max is too small, or one or more applications on the
system is using too small a value for the listen backlog in its call
to listen().

It is also possible that those settings are good, but one or more
applications have stopped calling accept() against their listen
socket(s) - perhaps they are saturated, or perhaps they are caught in
an infinite loop."

The total number of connections is limited only by your application, cpu load and the available memory and bandwidth. Since you say dropping one connection allows a new one I'd look at the application. First make sure it's not starved for memory or disk space or cpu time then check with the maker to see if there is a limit.

I assume you are uptodate on your ARPA patches so we don't have to worry about an HP software bug.

Ron

[rick jones]

Others have pointed-out what tcp_conn_request_max affects wuite well. My guess would be that the settings of maxfiles/maxfiles_lim is being reached - at that point the process cannot allocate any new file descriptors, and a socket descriptor is simply a file descriptor that happens to reference a socket rather than a file.

Less likely but still possible is hitting the system-wide limit on file descriptors - nfile.

There is indeed no hardcoded limit to the number of TCP connections a system can have.

[Hofmaenner]

This is most certainly not a tcp limitation. The saprouter service is per default limited to 800 connections. As for every connection an incoming and one outgoing connection is needed this gives you a limit of 400 connected users.

If more connections are needed you can increase the value to 2000 and configure multiple saprouter services. Check the -C and -Y options. This values are valid at least for saprouter from sap kernels 620/640.

Regards Michael