[OpenAFS] extreme slowness on windows client
Wed, 28 Jun 2006 22:19:24 -0700
On Wed, Jun 28, 2006 at 12:49:53PM -0400, Jeffrey Altman wrote:
> David Bear wrote:
> >> Follow the instructions in the OpenAFS for Windows release notes.
> >> Use the SysInternal's FileMon and DbgView tools to figure out what
> >> requests Windows is making and map them to the internal processing
> >> in the AFS Cache Manager to figure out why they are taking so long
> >> to complete.
> > well, this may be the only way, but it won't work. Both these systems
> > are used constantly by their primary users. I can't send them home for
> > a day while I do this.
> You can configure the monitors to log to a file and come back at
> the end of the day and grab the files. Minimal impact on your users.
> Or you can bump the log level on your file servers and monitor
> the traffic from that side of the world.
> > Are there any other known interactions that could be a problem?
> There are lots of known interactions that are problems:
> (1) clients that change their addresses or port numbers when
> communicating with pre-1.4.2 files servers will result in
> delays of 57 seconds each time the file server detects a
> change and there is a callback that is waiting to be revoked.
> (2) the windows client doesn't implement inline bulk status updates
> so performance is horrible when evaluating the contents of
> directories when there is only 'lookup' privilege.
> (3) you could be suffering from a bug in the client that results in
> a deadlock on one or more stat cache entries
> To be more helpful you will have to provide many more details:
> (1) exactly which release did you install on the windows client?
> (2) what version are your file servers?
> (3) your new dynamic addresses, do the client machines get the same
> addresses each time?
> (4) what operations are your users performing that are failing?
> (this you will get from the file monitor logs)
I solve the problem -- but I never diagnose the issue nor did I
control my changes to the system to see which really affected openafs.
I solved it by
1) removing checkpoint
2) removing openafs
3) reseting the ms tcpip stack using the netsh command.
4) reloading openafs
5) reloading checkpoint
After doing that -- openafs was snappy and worked well.
> Jeffrey Altman
College of Public Programs/ASU
Wilson Hall 232
Tempe, AZ 85287-0803
"Beware the IP portfolio, everyone will be suspect of trespassing"