1

What information can I gather from netstat listen queues?

Looking at the man page I can see that using "-L" in netstat it shows me the size of listen queues.

It tells me information about each column:

  • 1st number of unaccepted connections
  • 2nd number of unaccepted incomplete connections
  • 3rd number of maximum queued connections

I notice that whenever the 1st column tends to increment higher, my application tends to become less responsive and Nagios checks for open socket connections start to fail.

Is it typical/expected to have a non-zero number of unaccepted TCP connections? Or is this an indication of an application problem?

Example (with $port being an actual port number):

netstat -La | grep $port
tcp4  22/0/128        *.$port

Typically when the application is responsive the output looks like:

tcp4  0/0/128        *.$port
Improve this question

1 Answer 1

Reset to default
2

Haven't you answered your own question? When there are unaccepted connections the application gets sluggish. If you're wondering whether that behavior is expected then, yes, it is. If incoming connections are queuing the the amount of time spent in the queue increases the request latency for the client leading to the sluggish response you described. To fix the problem you need to either decrease the number of incoming connections (usually not an option) or add resources to the application. The latter can be accomplished either by increasing the resources available to the system in general or (and this is often the better option) adding nodes in a load balancing cluster.

Improve this answer
4
  • Thank you. I realized that there is a problem when that behavior occurs, but I was unsure as to whether it might be a TCP problem or an application issue. I did not know if queuing was expected or normal behavior for applications.
    – cheesesticksricepuck
    Dec 22, 2015 at 14:00
  • Queuing is normal behavior when the application can't handle the incoming connections as fast as they're coming in. It's a feature of TCP since its almost always preferable to have the connection queued instead of rejected.
    – David King
    Dec 22, 2015 at 14:03
  • Is there ever a scenario where you would see a high number of connections in queue, yet the application still remains responsive? Or should there NEVER be any connections in queue? Also, I'm guessing after a certain point of queuing there will eventually be rejections?
    – cheesesticksricepuck
    Dec 22, 2015 at 14:09
  • Not that I can think of off hand. Logically, if you have connections waiting in the queue then your client is sitting there waiting for a response to their request. Sitting around waiting for a response is kind of the definition of "sluggish". The way TCP was designed every new connection goes into the queue and then is processed as resources are available. That means there may always be a few connections queued but the number of connections should never get very high. The third number is the max queue depth. After that new connections will be rejected.
    – David King
    Dec 22, 2015 at 14:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .