Lyle,
It looks like I should check my messages more often! I think there are
several points that some folks might need. First, the number ov vfiles is
kept to a minimum in our cache due to our large chunk size (8M). This will
greatly reduce the overhead needed due to the number of files.
Also, we do experience a large amount of overhead if we force the cache
into reclimation. To avoid this, we purge ~30% of the cache each night to
make sure that we have room for new data the next day. This doesn't always
work so at times we are forced to purge the cache during the day.
I have no idea what the cache parms are at any given time, because we
adjust them with a script that determines the best parms given the recent
working environment. This takes a reboot to implement, but this happens
from time to time so the parms are always changing. It can take a bit of
time to reboot if we need to allocate more vfiles, but we have found that
it is worth the wait.
And finally, we are looking at striping the cache with Solaris. We are
planning to use 6GB caches on Ultras and will use two 4GB disks on two
controllers for cache (3GB & 3GB) and swap (1GB & 1GB). This is for our
larger cache requirements today, but we have talked about using much larger
cahces with 8GB disks or using a third disk/controller to grow to a 10GB
cache? We are still looking at these options for very large caches?
I'm not sure this helps this thread, but...
Lyle...Nice hearing from you again! Come down and see us soon!!! Mic
----------
> From: [EMAIL PROTECTED]
> To: Chuck Lever <[EMAIL PROTECTED]>; Daniel Bromberg <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]; David Winkel <[EMAIL PROTECTED]>
> Subject: Re: AFS/HTTP Server Performance
> Date: Monday, September 23, 1996 3:20 PM
>
> Daniel Bromberg <[EMAIL PROTECTED]> writes:
> > I remember reading a paper about this. I wish I could remember which
> > one. Basically, I think the code path to look up this information is
> > very long and unoptimized (no hints).
>
> It was probably stolarchuk's old paper, cited earlier in this thread.
> AFS has changed a lot since then (1991?). Most significantly, the cache
> is now integrated with the VM subsystem. Someone suggested that the
> difference between observed performance and the paper's claims must be
> a statistical anomaly. More likely, it's evidence of performance
> improvements subsequent to the paper's publication (and not entirely
> coincidental...)
>
> > It beats the heck out of me why AFS can't have O(1) cache lookups.
> > Hashing based on unique identifiers (AFS's fid's & chunk offset would
> > make a nice one) is something from my undergradudate years. Someone
> > made a comment about hardware vs. software, and AFS was limited by
> > being all in software. This doesn't really matter when it comes down
> > to O(f(n)) calculations. Hardware only improves by a constant
> > factor. It's the *algorithm* that matters.
>
> In fact, it does hash on the FID+chunk. Thus, cache lookups don't get
> slower with larger caches. The observed degradation with excessively
> large caches (and excessive all depends on the application) is probably
> related to cache reclamation, which is presently linear with respect to
> the cache size. As Joop suggested, tuning for optimum performance is
> unfortunately not quite as simple as "make your cache as big as you
> can."
>
> At one point, Mickey had good reason to use a 2GB cache, because his
> applications demanded it. That would be outrageously large for most
> uses.
>
