08-07-2013 11:50 AM
Checking "netstat -p tcp" with before after I've noticed sporadic "requests droppped due to full queue".
I've raised tcp_conn_request_max to 24576 some months ago and still happens from time to time.
I know the dropping may be because the application is using a small backlog on listen() or because it's busy and not calling accept() fast enough. I'm trying to investigate that and have some doubts.
1) The listen(2) man page says "backlog is limited to the range of 0 to SOMAXCONN, which is defined in sys/socket.h. SOMAXCONN is currently set to 4096". I checked the file and it says 4096.
So, Is there any point in raising tcp_conn_request_max? The app will really be limited to just a 4096 backlog size?
2) I suspect the dropping may be related to spikes in load causing delays in calling accept().
Any ideas on how can I verify this hypothesis? (source code not available)
3) By the way, the app is Orga OPSC online charging. If any of you has it running and could provide all his/her tcp/ip stack values, it would be great (I know the systems are always differente, but it'd help). I'm attaching a script that could help dump the complete tcp/ip stack.
08-07-2013 12:10 PM
Consulting the tao of Rick Jones on tcp_conn_request_max....
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. 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.
Since you've made it a huge number already...one feels compelled to ask if you've gone back to the vendor regarding this issue?