> Lisa Giacchetti <[EMAIL PROTECTED]> writes:
> > sizes and number of files. Finally since we had enough memory to do so, we
> > increased the amount of cache kept in memory. This instantly improved the
> > situtation. The current config we are running with is:
> >
> > GRANDE="-stat 2800 -dcache 4608 -daemons 7 -volumes 256"
> >
> > From my notes I have down that dcache indicates the number of cache item
> > entries you want cached in memory. We set this to 75% of the # of vfiles
> > in the cache. There is a formula we used to figure out the # of vfiles
> > in the cache
>
> dcache structures are "chunk descriptors", and don't actually contain
> data. They are in fact a cache of the "CacheItems" file which lives in
> the data cache directory (/usr/vice/cache). This descriptor is fairly
> small, but must be in memory before the data from its chunk can be read
> or written. The tradeoff is that these dcaches are often accessed via
> a hash table with linked-lists of overflow buffers, so if the
> linked-lists become _very_ large, it becomes expensive to touch
> new chunks.
>
> Your configuration suggests that you have relatively few, large files,
> and the default chunk size of 64K. Did you try using "-dcache 2304
> -chunk 17" ?
>
I'm not sure if we ever decreased the chunk size. I know we made it
bigger but many or those changes were made before my group became primary
admins for the afs cell. THerefore I don't have a lot of the specifics.
Basically since the consultant was here we have not changed anything and
the system is running really well.
> 75% of the vfiles in the cache seems high unless all the vfiles are in
> use. Usually, only about 50-75% of the vfiles are used.
>
> > the tuning of the parameters above and finally had a Transarc consultant
> > come to our site for a two day consulting stint ($$). He helped us tune the
> > cache parameters to what we have above, in about a half hour. This is just
a
> > strong pitch for more technical assistance on issues like this via phone
> > support.
>
> There are a few standard suggestions that can be made, but they pretty
> much amount to using the appropriate rc.* file. Other than that, it
> becomes something like the story of the refigerator repairman: "$5 for
> hitting it, $95 for knowing _where_ to hit it." It really takes a lot
> of experience to do this quickly -- and even despite that, finding the
> OPTIMUM settings for unusual configurations requires repeated
> experiments.
>
> You shouldn't hold this against the phone support folks, it's really
> outside their job description.
>
>
What I'm saying is that it needs to be someones job and if the telephone
support staff does not have the expertise then we should be directed to the
folks that do. I know transarc can not possibly have info for every machine
configuration that exists but there have to basic categories of systems with
deviations from those. Other companies will have someone log in over the net
to gather info and check the running system when needed. Most of these also
have a better set of diagnostic tools as well.
Lisa
>
>
