[Server-devel] Squid tuning recommendations for OLPC School Server tuning...
Martin Langhoff
martin.langhoff at gmail.com
Mon Sep 22 23:42:21 EDT 2008
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
More information about the Server-devel
mailing list