Kevin Hildebrand wrote:
> The other parameter I've found useful is to raise the number of server
> threads (the -p argument to the fileserver). In our case the value is
> set at 25 which is the maximum that can be specified without the
> fileserver dumping core in a few hours.
Given the implementation of the threads package, it's possible that the
true reason for your gains lies in the various data structures whose
sizes are tuned based on the number of threads, and not on the actual
number of threads. Considering that I've never actually looked at your
servers, odds are pretty good that I'm wrong :-). Try "-cb 65534", and
experiment with -rxpck (>400), -s (>600), -l(>600), and -b(>120).
How do you measure improvement? In other words, you say you've found
"-p 25" to be useful. How, exactly, is it useful?
> And while I'm on the subject, during my performance monitoring I'm
> noticing regular periods of sluggishness on all three of these
> fileservers. The periods occur every 16 minutes at which time there's
> a burst of disk I/O and a large drop in network traffic. The pauses
> one any one server don't necessarily coincide with the pauses on the
> other two, so I suspect the problem is local to the fileserver. All
> three servers are DEC Alphas running DU4.0 and the latest fileserver
> binaries. The machines do nothing but AFS fileservice and I've
> commented everything out of cron. Is there something in the
> fileserver itself that runs every 16 minutes?
Nothing obvious. How long does each period last?
