Squid reconfigure can indeed take a long time. Especially when Squid uses lots of memory and starts helpers. Starting helpers takes a large amount of kernel resources when Squid is large, e.g. 2+ GB since it forks itself and replaces its copy by a new process. The fork can take a long time. If you use a URL rewritor you can easily have 24 or more of them and this makes 24 copies of a large process. How large is squid ? Can you post the output of ps -o pid,stime,sz,vsz,rss,args -C squid I wrote a test program to test the performance of forking X times a large process. I can post it if you are interested. Marcus On 07/02/2012 05:08 AM, Mr J Potter wrote:
Hi all, Does anyone have any tips on how to fix this issue: We've just moved to squid3 from squid2, and now when we do squid3 -k reconfigure we get about 30 seconds of squid refusing/failing to forward requests while it rejigs itself. I don't know if this is squid3 rescanning the cache or doing something with squidguard (we have a fairly complex+large squidguard setup)? I don't think this happened with squid2. What can we do to make this less noticeable? - make it reconfigure faster? - multiple squid servers - can we do failover somehow (either proxy DNS record points to them both, or they automatically redirect (is this what cache peers are for?))? - go back to squid 2 - I didn't see any end user benefits of squid3 over squid2... any help would be greatly appreciated. thanks Jim Potter UK
