Re: [squid-users] slow reconfigure on squid3

From: Marcus Kool <marcus.kool_at_urlfilterdb.com>
Date: Wed, 04 Jul 2012 10:54:49 -0300

On 07/04/2012 04:49 AM, Mr J Potter wrote:
> Hi all,
>
> thanks for your responses...
>
> versions - I use the standard ones with Debian squeeze (2.7.stable9 and 3.1.6)
>
> Yes there are lots of helpers - 25 NTLM helpers and 10 squiduguard
> helpers, so this could account for slow reconfig.

I have seen a performance as low as 1 second per helper for a
Squid process of approximately 4 GB.
How large is your Squid process and how long does it take to
start the helpers?

> Upgrading to 3.2 seems like a good bet - are there ready-rooled squid
> 3.2 debs available for Squeeze or do I have to make my own?
>
> We currently run squid in 3 different flavours of authentication -
> NTLM for PCs, ident for macs and digest for guest network, so have 3
> distinct squid setups running on our proxy server. Would it be worth
> setting these all up as non-caching, then set up a parent caching
> server, or will setting them up as cache peers make them share their
> caches at all?

This would work well, IF
the "non-caching" Squid has a small memory footprint and needs all the
helpers and the parent Squid has a large memory footprint and
does not need helpers.
Maybe the child can have a small memory cache instead of no cache.

Squidguard also needs more resources than ufdbGuard since it
uses 10 database caches and a database on disk (which is cached in
the file system buffers) where ufdbGuard uses one copy of
the URL database in its own memory. The database format of
squidguard uses 2-4 times more bytes than the format of
ufdbGuard reducing further the need for memory resources.

Marcus

> cheers
>
> Jim
> UK
>
> On 2 July 2012 14:44, Marcus Kool<marcus.kool_at_urlfilterdb.com> wrote:
>> 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
>>>
>>>
>>
>
>
Received on Wed Jul 04 2012 - 13:54:55 MDT

This archive was generated by hypermail 2.2.0 : Wed Jul 04 2012 - 12:00:02 MDT