Re: unresponsive cache and stats with a loaded cache

--MimeMultipartBoundary
Content-Type: text/plain; charset=us-ascii

Hi

> >> Once I chased the way squid uses its L1/L2 directory structures, and
> >> it appeared to me that excessive amount of directories slows things
> >> down quite a bit. I don't recall exactly, but I have an impression that

> >that a configurable number of files (default 512, maybe a little too high)
> >are written to a directory before going to the next one. Alternating
> >among all cache_dirs is still done, too.
>
> I decided to apply the patch on a real production cache this weekend and
> have gathered one day of business-hours (08:00h-18:00h) usage data (data
> has been gathered with my Squid timer patch). The results are quite good
> if you compare the results of last Friday and today (Monday):
.
.
.
> open(2)'s for write have dropped from 35ms to 5ms, open(2) for read had
> dropped from 24ms to 8ms, read(2)'s have dropped from 12ms to 8ms. This
> all leads to 46.3% idle time, i.e. Squid is waiting in select(2) for
> something to happen. Waiting for disk I/O (diskr/w+openr/w) has dropped
> from 68.37% to 25.93%.

A question though - isn't this only going to be useful on a
new,empty cache (or a cache with only a few files in it).

Given a totally full cache you are still going to get the original
distribution, aren't you? So for a cache like ours (totall stuffed full
the whole time) you wouldn't see any real benefit...

Oskar

-- 
"Haven't slept at all. I don't see why people insist on sleeping. You feel
so much better if you don't. And how can anyone want to lose a minute -
a single minute of being alive?"				-- Think Twice
--MimeMultipartBoundary--