[SQU] Full cache prevents TCP_MEM_HIT?

Is it possible that a full Squid cache could prevent TCP_MEM_HITs?

I've got 2 machines that are running Squid (v2.3S4 + released patches)
caches. Both machines are x86 boxes running Linux 2.2.16 and have
plenty of RAM and disk space. Both caches are configured the same
in terms of RAM and disk space allocated to them.

Both caches are also configured to use the Adzapper redirector, which
turns most advertisements into a tiny GIF file. Both machines are
kept up to date with the same version of the redirector. Having so
many ads changed into the same GIF file has made for a pretty good
TCP_MEM_HIT rate (about %5 of requests).

That is until a few weeks ago, when the cache on one of the machines
filled up. (Not a problem. Up to then, both caches were below the
specified max percentage, so there were a lot of stores and few
unlinks.) Until then both machines behaved identically.

Now the machine with the full cache (I'll call it cacheA) and the
machine whose cache is not yet filled (cacheB) show dramatically
difference rates of TCP_MEM_HITs. The ads on cacheA are still
zapped, but that tiny GIF file is now read out of the disk-based
cache to satisfy requests, while cacheB still serves them out of RAM.
Last week cacheA only had 4 (yes, f-o-u-r) TCP_MEM_HITs. Jeez!

I don't see how having a full cache could possibly have anything to do
with the rate of RAM-based HITs, but I can't think of any other
difference between my 2 caches. Sure, more files means more bits used
to track them, but I have plenty of RAM allocated to Squid. Plus, the
reduction on TCM_MEM_HITs was pretty sudden, as opposed to dwinding as
the number of cached files rose.

Any thoughts on what could be going on here?

Thanks.

*** Steve Snyder ***

--
To unsubscribe, see http://www.squid-cache.org/mailing-lists.html