Re: [squid-users] Long running squid proxy slows way down

From: Gavin McCullagh <gavin.mccullagh_at_gcd.ie>
Date: Sun, 26 Apr 2009 21:38:20 +0100

Hi,

On Sun, 26 Apr 2009, Amos Jeffries wrote:

> almost. The final one is:
> -> aggressive until swap_usage < cache_swap_low
> which could be only whats currently indexed (cache_swap_log), or could
> be less since aggressive might re-test objects for staleness and discard
> to reach its goal.

I had presumed that squid had a heap or other $STRUCTURE which kept the
cache objects in order of expiry so they could be purged immediately they
expired. Thinking about it though, perhaps that would kill off all
possibility for TCP_IMS_HITs?

Sorry to be constantly peppering you with these questions, I just find it
all very interesting :-)

>> Would it be better to calculate an absolute figure (say
>> 200MB) and work out what percentage of your cache that is? It seems like
>> the 95% high watermark is probably quite low for large caches too?
>
> I agree. Something like that. AFAICT the high being less than 100% is to
> allow X amount of new data to arive and be stored between collection
> cycles. 6 GB might be reasonable on a choked-full 100 MB pipe with 5
> minute cycles. Or it might not.

As I mentioned we have a 20GB gap by default and are on a 40MB pipe which
is often quite choked. I can't say we've noticed the collection cycles but
maybe we're not measuring it right.

I'll probably change the thresholds to 98%,99%.

>> Would it make more sense for squid
>> to offer absolute watermarks (in MB offset from the total size)?
>
> Yes this is one of the ancient aspects remaining in Squid and different
> measures may be much better. I'm having a meeting with Alex Rousskov in
> approx 5 hours on IRC (#squiddev on irc.freenode.net) to discuss the
> general store improvements for 3.2. This is very likely to be one of the
> topics.

Please do let us know how you get on :-)

Thanks as always,
Gavin
Received on Sun Apr 26 2009 - 20:38:24 MDT

This archive was generated by hypermail 2.2.0 : Mon Apr 27 2009 - 12:00:02 MDT