Parameters TCP

[Marcial Ruiz]

We are experimenting disconnections of the oracle clients. They connect to BD Oracle 9i
R1 on HP-UX.

Oracle Support recommends to me , set these values:

tcp_time_wait_interval set to 60000 (default)
tcp_xmit_hiwater_def set to 65536 (default 32768)
tcp_recv_hiwater_def set to 65536 (default 32768)
tcp_conn_request_max set to 10240 (default 4096)
tcp_syn_rcvd_max set to 10240



Questions:
=========

1.- It's well fixed?
2.- What is repercussions in the performace?
3.- Any conclusions of the problem ?

Thanks,

[Ron Kinner]

Can't say if it will fix the problem. Seems unlikely to me. None of the parameters will keep an established connection from dying. But none of them will hurt anything - might use a bit more memory is all. If you are really getting more than 4096 tcp_conn_request at one time then your system is probably overloaded.

ndd -h tcp_xmit_hiwater_def

tcp_xmit_hiwater_def:

The amount of unsent data that triggers write-side flow control.
[4096,-] Default: 32768 bytes

If your network is backing up so that you reach the default limit then you either need a lot more bandwidth or there is a problem such as a duplex mismatch or noisy cable.

You might look at
netstat -s
to see if you see any sign that possible connections are being dropped or if you have a lot of retransmissions or other signs of a bad network.

Also
lanadmin
lan
display
(look on the second page for errors)

Ron

[Colin Topliss]

There is one that you are missing. Its very wise to set a timeout value for tcp_fin_wait_2_timeout or else you will find a number of clients sat there in a FIN_WAIT2 state. No timeout is set by default (value = 0) so the client connections never close. The only way to clear them is to reboot.

You tend to get this state when the client closes the connection abnormally without sending a termination to the server side.

Col.

[Marcial Ruiz]

What I can obtain fixing tcp_fin_wait_2_timeout with respect to my problem ?

Will it my problem ?


Thanks,

[RolandH]

Hi Marcial,

I have a annotated ndd document, perhaps it can help you a bit.

Roland

Document is attached!!

[Marcial Ruiz]

additionally

What is the values maxim allowed of tcp_syn_rcvd_max?

10240 ?


Thanks,

[RolandH]

Maximum is 10000 for this value. See my text I have attched before.

Roland

[RolandH]

Could it be that Oracle has made a typo and the value must be 1024 and not 10240?

Roland

[rick jones · Accepted solution]

I suspect none of those have anything to do with a disconnect issue. Also, Oracle is incorrect about the default value of tcp_conn_request_max.

In the past, Oracle has had this habit of confusing HP-UX and Solaris ndd settings.

Other than that, the parms shouldn't harm anything. Setting the default TCP window size to 64KB will help with bulk transfers over longer distances and will also help with connections over GbE - the bandwidth delay product for local GbE is greater than 32768 bytes.

As for FIN_WAIT_2 connections, if one has to set the explicit FIN_WAIT_2 timer, it suggests buggy applications. If an application calls shutdown(SHUT_WR), FIN_WAIT_2 is a perfectly valid receive-only state.

Now, it could be the case that the remote is buggy because it is using a RST. Or it could be that the remote could have simply gone poof. Indeed, that could leave a FIN_WAIT_2 state indefinitely.

However, if the application has only called shutdown(SHUT_WR), then _it_ should be running a timer - only the application can reliably decide how long is too long to not receive anything on a recv-only connection. TCP has no way to know that. That is why I consider the fine_wait timeout to be a kludge.

If an application calls close(), then TCP on HP-UX 11 will automagically enable a keepalive probe after tcp_keepalive_detatched_interval time units. If the remote TCP does not respond within tcp_ip_abort_interval time units, the connection will be terminated. If the remote does respond, it means the remote application has not called close(). That too then is an application issue that needs to be resolved - it means that the applications have a broken shutdown sequence.

[Colin Topliss]

I like this statement:

As for FIN_WAIT_2 connections, if one has to set the explicit FIN_WAIT_2 timer, it suggests buggy applications. If an application calls shutdown(SHUT_WR), FIN_WAIT_2 is a perfectly valid receive-only state.

You mean we can actually GET an application which is NOT buggy???

:-)

[rick jones]

Well, with enough time and money, one can get applictions that provide the illusion of being bug-free, but I don't think I'd go any further than that :)

I just don't like seeing kludges being put into the stack to cover the backsides of broken apps...