Esther Filderman <[EMAIL PROTECTED]> writes:
> That said, we're using the default block size. I never thought before
> to change this! I think I will look more into it, it may enable us to
> use a smaller cache & have less frequent problems.
My intuition would be to go the other way around; use the same size cache
you have, but use a larger block size, if the reason for the cache size is
that the system is primarily handling large files. That will mean fewer
entries in the cache, which should speed up cache access without losing
your ability to work on really large files entirely out of cache.
Some sort of coherent guide to cache tuning would be *very* nice, though.
We've even talked to Transarc a little bit about this before, but there
doesn't seem to be a solid set of tested principles to draw on. There are
a lot of rumors and legacy knowledge out there, and I have no idea how
much is still accurate.
For example, I have been told that the cache manager algorithm uses a
linear search at some point, which means that the more blocks you have in
your cache, the more performance degrades since it's harder to find things
in the cache. Given that the cache is a directory full of a lot of files,
and the standard Unix directory search pattern is linear, this *sounds*
reasonable, but I have no idea if the code has since been improved so that
this is no longer the case, and all of the implications of that knowledge
no longer apply.
The cache block size is one of those tunable parameters that intuitively I
would expect to help a lot (like using a small block size for a web server
serving content out of AFS, since most web content is small), but I'm a
little lost when it comes to picking specific values.
Something that watches the AFS client daemons and logs their cache access
patterns and then gives you a breakdown of how large the files you're
caching are, what kind of turnover the cache is seeing, and where the
bottlenecks are and how you can improve them with the tunable parameters
would be really nice. For all I know, it might even already exist
somewhere deep in contrib or on some random site somewhere. :) (Do you
ever get the feeling that all of us are constantly independently
reinventing tools?)
--
Russ Allbery ([EMAIL PROTECTED]) <URL:http://www.eyrie.org/~eagle/>
