On 7/11/2011 6:01 p.m., Justin Lawler wrote:
Thanks Amos.
Checked that ' mgr:filedescriptors' - wasn't aware of this functionality before.
95% of the file descriptors have the Description ' Waiting for next request'
Aha.
---------------------------------------------------------------------------------
21 Socket 40 222* 5237 10.1.5.53:53279 Waiting for next request
22 Socket 30 264* 5237 10.1.5.53:53029 Waiting for next request
23 Socket 95 266* 540530 10.1.5.53:54489 Waiting for next request
24 Socket 110 321* 539782 10.1.5.54:53322 Waiting for next request
25 Socket 49 306* 5344 10.1.5.53:53435 Waiting for next request
26 Socket 29 295* 130535 10.1.5.54:51444 Waiting for next request
---------------------------------------------------------------------------------
This is in a performance lab, with a load injector hitting squid, trying to simulate a production system. Could it be a problem with the load injector not closing connections? Could the load injector have opened many connections when squid was unresponsive (because ICAP was unresponsive), and those connections never got closed?
Possibly, I cant really say what is happening in that client software,
but it certainly seems so.
Yes, and No.
These are client persistent connections in their keep-alive state
between requests. persistent_request_timeout controls this with a
default of 2 minutes between requests. *if* a connection is re-used
before that the counter resets and it can stay open a very long time.
But if it does not get used then Squid will close it.
Amos
