[OpenAFS] Re: Fair bandwidth distribution, performance of OpenAFS on win32

[Matthias Gerstner]

> First of all: versions? Server version is most interesting to me, but
> the various clients would be good to know (in particular the Windows
> ones).

Sure. It's a pretty heterogenous setup:

* The server is running Gentoo Linux with kernel 2.6.35 at the time
  being. OpenAFS server is at version 1.4.12.1. Most of the Linux client
  machines run on the same Linux and OpenAFS version.
* Some of the Linux clients also run on custom installations using
  Ubuntu, Debian or SuSE Linux at versions I don't really know at the
  moment.
* The Windows clients are Windows7 64-bit installations running in my
  case OpenAFS 64-bit version 1.5.74
 
> If possible: "don't do that" :) The user is going to get faster compiles
> on local disk anyway, and I don't expect e.g. intermediary .o files to
> be very important.

That's understood. The users that do it don't do it for fun but because
they have sources and sometimes also binaries available on different
machines without having to sync data at different places all the time.

The big compiles are done for people being able to access certain
defined versions of a software build easily.

> What fileserver parameters are you running with? If you are running with
> the defaults you are going to be sad. If you are running with the
> defaults, the first suggestion is to try '-L -p 128' to see if that
> improves things.
> 
> Also, on the linux client side, what options are you giving to afsd?

That might be just the right pointer. I'm new to tuning OpenAFS. Until
now I have focussed on the client side parameters. My current afsd
parameters are as follows:

-fakestat -stat 5000 -dcache 6000 -daemons 3 -volumes 256 -chunksize 20
-files 50000

The files might be overkill. I've been experimenting with these settings
a while ago.

As goes for the server it seems I'm actually using the default right
now. I'll see into it if increasing the values as suggested will improve
things for me.

> If you know what volumes are giving you grief, you could move that
> volume (or volumes) to be on their own small fileserver, which would
> isolate their activity from the rest of the cell.

That would be at least a measure of last resort. The affected volumes
are only of small amount so it could be done I guess.

> When it's being slow, try running 'rxdebug <fileserver>' and 'rxdebug
> <fileserver> -rxstats' and put the results somewhere if you're
> comfortable with sharing them.

I think I go for the server parameters now and if it doesn't improve
enough I will investigate further.

Thank you for the information so far.

Matthias

-- 
Matthias Gerstner, Dipl.-Wirtsch.-Inf. (FH), Senior Software Engineer
e.solutions GmbH

Am Wolfsmantel 46, 91058 Erlangen, Germany

Registered Office:
Pascalstr. 5, 85057 Ingolstadt, Germany

Phone +49-8458-3332-672, mailto:Matthias.Gerstner@esolutions.de
Fax +49-8458-3332-20672

e.solutions GmbH
Managing Directors Uwe Reder, Dr. Riclef Schmidt-Clausen
Register Court Ingolstadt HRB 5221