On 15/04/2014 9:53 p.m., Steve Hill wrote: > > I'm trying to debug some slowness issues with Squid 3.4.4. This is > currently under reasonably light use and every so often it becomes very > slow. > > From what I can tell, the client sends a request with Negotiate auth > credentials in it. The proxy should respond with a 407 and the > negotiate challenge, but instead it sometimes just sits there for > ages... sometimes for a minute or so! (I'm not 100% convinced that this > is specific to Negotiate auth though). Squid does not appear to be > running out of file descriptors. > > The problem is intermittent, which is making debugging a pain. I have a > tcpdump running and full logging turned on in squid so hopefully I can > catch some useful information the next time the problem occurs. > > My question is: Once I've identified a specific request that has > experienced the problem, and want to track what Squid was doing with > that request, is there any sensible way of filtering the cache.log to > exclude the other requests that were happening concurrently? We are still in the very slow process of integrating a master transaction ID. Meanwhile ... given an ALL,9 (or -X) trace in cache.log you should be able to track which [callNN] block of code received the request and which other callNNN were created by it. From there it is a matter of tracking call-by-call through the log which ones were actually executed. And so on. > > Secondly, does anyone have any suggestions for what specific logging I > should turn on, rather than logging everything, since logging everything > slows the proxy down significantly? DNS or the helper lookup are places I'd focus on to see how long they are taking. You can get an idea of that from the call trace as well as from the cachemgr reports of their usage and response times. Amos
