Re: [Server-devel] Squid tuning recommendations for OLPC School Server tuning...

From: Martin Langhoff <martin.langhoff_at_gmail.com>
Date: Tue, 23 Sep 2008 15:42:21 +1200

On Tue, Sep 23, 2008 at 3:09 PM, Adrian Chadd <adrian_at_squid-cache.org> wrote:
> I've looked into this a bit (and have a couple of OLPC laptops to do
> testing with) and .. well, its going to take a bit of effort to make
> squid "fit".

Any way we can kludge our way around it for the time being? Does squid
take any signal that gets it to shed its index?

> There's no "hard limit" for squid and squid (any version) handles
> memory allocation failures very very poorly (read: crashes.)

Is it relatively sane to run it with a tight rlimit and restart it
often? Or just monitor it and restart it?

> You can limit the amount of cache_mem which limits the memory cache
> size; you could probably modify the squid codebase to start purging
> objects at a certain object count rather than based on the disk+memory
> storage size. That wouldn't be difficult.

Any chance of having patches that do this?

> The big problem: you won't get Squid down to 24meg of RAM with the
> current tuning parameters. Well, I couldn't; and I'm playing around

Hmmm...

> with Squid on OLPC-like hardware (SBC with 500mhz geode, 256/512mb
> RAM.) Its something which will require quite a bit of development to
> "slim" some of the internals down to scale better with restricted
> memory footprints. Its on my personal TODO list (as it mostly is in
> line with a bunch of performance work I'm slowly working towards) but
> as the bulk of that is happening in my spare time, I do not have a
> fixed timeframe at the moment.

Thanks for that -- at whatever pace, progress is progress. I'll stay
tuned. I'm not on squid-devel, but generally interested in any news on
this track; I'll be thankful if you CC me or rope me into relevant
threads.

Is there interest within the squid dev team in moving towards a memory
allocation model that is more tunable and/or relies more on the
abilities of modern kernels to do memory mgmt? Or an alternative
approach to handle scalability (both down to small devices and up to
huge kit) more dynamically and predictably?

cheers,

m

-- 
 martin.langhoff_at_gmail.com
 martin_at_laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
Received on Tue Sep 23 2008 - 03:42:23 MDT

This archive was generated by hypermail 2.2.0 : Tue Sep 23 2008 - 12:00:04 MDT