Re: Improve TCP_MEM_HITS

On Sat, 24 Jun 2000, Mike Brudenell wrote:

> To date I've edged Squid's cache_mem setting up to 300Mb on each machine.
> This, accordint to "top", leaves Squid running around the 500Mb "SIZE", of
> which about 490Mb is "RES"(ident). Although the system has swap space in
> use (currently 514Mb in use, with 998Mb free) there is no swapping activity.

There are no hard and fast rules. The debate on whether or not one should
avoid file IO because the operating system paging is better has been
raging for as long as paging was invented.

But keep this in mind. If your "hot" cache keeps stuff in memory that
remains there for a long time but eventually gets evicted because new
stuff comes in, you're just postponing the write to disk without saving
any IO. I think some people overestimate the importance of keeping hot
objects in memory. The hot cache should hold items that are referenced a
lot in a relatively short time frame. It also helps when downloading large
stuff (see maximum_object_size).

Anyway, I prefer to keep the system from page faulting at all, because I
subscribe to the philosophy that Squid knows far better how to page out
unneeded stuff than the operating system. My caches maximize disk storage
over cache_mem (the number of items in the disk cache is responsible for
most if the memory usage of Squid, so I allot all of the memory that's
left after the disk cache fills up to cache_mem.

As to Solaris' alleged trade off between disk cache and free memory: if
Squid decides it should get rid of an object in the memory cache, it
doesn't make sense to let it linger in the operating system filesystem
cache.

So, my recommendation would be: start with a cache_mem of 64M and wait
'til your disk cache fills up. Then add three quarters of your free memory
to the cache_mem (that leaves a bit for fragmentation over time).

Cheers,

                                -- Bert

Bert Driehuis, MIS -- bert_driehuis@nl.compuware.com -- +31-20-3116119
Dihydrogen Monoxide kills! Join the campaign at http://www.dhmo.org/
Received on Sat Jun 24 2000 - 15:39:13 MDT