Re: tcp_conn_request_max and "requests dropped due to full queue" (302 Views)
Reply
Frequent Visitor
Francisco Rebolledo
Posts: 2
Registered: ‎11-02-2010
Message 1 of 3 (312 Views)

tcp_conn_request_max and "requests dropped due to full queue"

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.

 

Frequent Visitor
Francisco Rebolledo
Posts: 2
Registered: ‎11-02-2010
Message 2 of 3 (311 Views)

Re: tcp_conn_request_max and "requests dropped due to full queue"

 
Trusted Contributor
donna hofmeister
Posts: 191
Registered: ‎08-29-2008
Message 3 of 3 (302 Views)

Re: tcp_conn_request_max and "requests dropped due to full queue"

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?

 

 

The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.