iPlanet - Error accepting connection -5974, oserr=233 (Insufficient resources)

[Jon Mattatall]

We recently retired an L1000 running iPlanet and VirtualVault. We saw these errors A LOT during heavy use, with the additional bonus of iPlanet dying at random intervals.

As I recall, we did increase values for ninodes, nfiles, semmni, and some other semaphore values. Matters improved a bit, but heavy traffic was still enough to bring iPlanet down.

We finally managed to move off the platform, but the underlying problem was still there.

[rick jones · Accepted solution]

those TCP settings aren't heinous, but I doubt they will speed-up iPlant much if at all.

going to one minute on the tcp_ip_abort_interval is a bit harsh in my mind - assuming the minimum retransmission timeout (RTO) is in effect then that means that there will be fewer retransmissions of a given lost segment before the transport aborts the connection - if you believe that there are "never" any "normal" times when the network is paused or really really busy for less than 10 minutes, but more than one I guess it is OK.

the keepalive setting is ok i guess.

[masrudyn]

mark/jon

thanks for your replies. so it seems to me that most sites running iPlanet on HP-UX seems to be faced with this problem. :-( I guess I will monitor the server; if none of the users complain, I'll just leave it as is.

rick,

thanks alot for your useful commments on the settings. I'll pass on your comments to the sysadmin team.

[masrudyn]

hi rick,

just wanna clarify with you regarding the parameter tcp_ip_abort_interval. You mentioned that setting it to a lower value would mean fewer transmission when there is a lost segment.

I'm just curious - would this affect long running transactions? Coz occasionally, my webserver will connect to a middleware which sometimes takes a long time to complete. (sometimes 1-5 mins)

Would setting the parameter lower mean that my long running transactions time out easily?

[rick jones]

The tcp_ip_abort_interval is how long TCP will wait for an ACK of a given segment from the remote TCP. It is not affected by application service times. So, if you have an application that takes 5 minutes to service a request, that is fine as far as tcp_ip_abort_interval is concerned. TCP will have ACKed the data long before that.