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
