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

On 23/09/2008, at 1:42 PM, Martin Langhoff wrote:
>
>> 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?

That's about the worst thing you can do; it will go down hard if it
hits that limit.

It's not that Squid's memory use will necessarily increase over time
(at least, when cache_mem is full); rather, it's that in-transit
objects and internal accounting use memory on top of cache_mem. As
such, intense traffic (e.g., lots of simultaneous connections) will
cause more memory use. Likewise, if you use disk caching, there's a
certain amount of overhead (I believe about 10M of memory per G of
disk).

FWIW, one of my standard squid packages uses 48M cache_mem, and I
advise people that it shouldn't use more than 96M of memory (and that
rarely). However, that's predicated on a small number of local users
and no disk caching; if you have more users and connections are long-
lived (which I'd imagine they will be in an OLPC deployment), there
may be more overhead.

> - The XS will (in some locations) be hooked to *very* unreliable
> power... uncontrolled shutdowns are the norm. Is this ever a problem
> with Squid?
>
> - After a bad shutdown, graceful recovery is the most important
> aspect. If a few cached items are lost, we can cope...

Squid will handle being taken down roughly OK; at worst, the
swap.state may get corrupted, which means it'll have to rebuild it
next time around.

Overall, what do you want to use Squid for here; caching, access
control..? If you want caching, realise that you're not going to see
much benefit from such a resource-limited box, and indeed it may be
more of a bottleneck than is worthwhile.

Cheers,

--
Mark Nottingham       mnot_at_yahoo-inc.com