Re: [squid-users] Squid getting too big?

On Fri, Aug 10, 2001, BAARDA, Don wrote:

> Yes, but there is more to consider than just how well the memory allocator
> works for Squid in isolation.
>
> An OS knows the whole context of the system, and can take that into account.
> An application that just consumes a larger and larger chunk of memory for
> it's own internal allocator can screw up the OS's attempts to juggle RAM,
> swap, and disk cache between _all_ the processes running on the system. In
> the end your highly tuned memory allocator can be bottlenecked by the OS's
> generic virtual memory management.

Ah. But in practice, the 'memory allocator' in a UNIX OS isn't what
you think it is. Its just a layer that sits on top of either some calls
to sbrk(), or some calls to mmap() to grab memory pages. The memory
manager _could_ provide lots of feedback to the kernel, but I haven't
seen one that does this yet (in modern unices, and believe me I'd like
to be wrong here.)

> Implementing your own memory manager duplicates functionality. This means
> two chunks of code running in memory, two lots of source to maintain, and
> two places to introduce bugs. I know that the memory allocation stuff is
> small in the context of everything, but I'm reminded of the saying "take
> care of the cents, and the dollars will take care of themselves". Code bloat
> is rarely caused by duplication of massive components, usually its
> duplication of heaps of tiny pieces, which also makes it much harder to fix.
>

> I'm always wary of any efforts to duplicate and tailor basic OS
> functionality for a particular application. By just leveraging the OS, you
> save yourself heaps of work, and you get free upgrades as the OS is
> improved. If the OS's implementation is flawed, I figure it's better value
> to fix the OS than re-invent it. I think the reason the NOVM version of
> squid was so effective (at least on Linux) was because it tossed the whole
> idea of managing its own memory cache and just relied on the OS's disk
> caching to do the work for it.
>
> However, I'm not a Squid developer. I am speaking generally, and I do know
> that in specific cases, there can be significant benefits from re-inventing
> a special wheel. I trust the squid developers know what they are doing :-)

The problem (heh) with UNIX is that its generic. Its good at everything
it tries to do, but good doesn't cut it when you're trying to push an
envelope. Squid pushes the system envelope, and I know what some of the
commercial caches do to their host OS (it makes tuning squid look like
childs play :)

Yes, NOVM was effective for that reason. In fact, the new code i'm working
on looks a lot more like NOVM then it does anything else. But, even with
NOVM, squid still needed to allocate and free lots of little fixed-sized
structures over and over again (it just didn't try to keep the object
in memory).

Adrian
Received on Thu Aug 09 2001 - 19:58:55 MDT