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

[Jeffrey Altman]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig4A821038F60D04D9DE323892
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 11/10/2010 12:42 PM, Matthias Gerstner wrote:
> Hello everybody,
>=20
> I have a question regarding bandwidth (or more general: resource)
> allocation in an OpenAFS setup. I'm maintaining a small installation
> with one server and a dozen of clients. Server and most clients run on
> Linux. Some clients also on MS Windows 7. Authentication is done by way=

> of MS Server 2008 AD.
>=20
> The problem I have is that time and again a user needs to perform rathe=
r
> performance killing operations on AFS. That is compiling a large softwa=
re
> project with accessing a large number of small files and also producing=

> a large number of files.
>=20
> In this situation other users with moderate load on AFS suffer a bad
> user experience. That is not necessarily that absolute bandwidth is too=

> low. It is rather that interactive work becomes annoying as operations
> on AFS tend to block repeatedly. For example writing a small text file
> can takes up to five seconds until suddenly everything goes back to
> normal.

For starters:

* what version are the servers?

* what configuration parameters are the servers running with?

* are the users experiencing the delays on the same machine or another?

* what versions are the clients involved?

* how many afs file system objects are active in a ten minute window
when the slow down occurs?

> I wonder what would be the best approach to improve the user experience=

> for such cases. A low-level approach like extensions to the TCP/IP stac=
k
> on the Linux server machine might be one example. But I feel that given=

> the complexity of OpenAFS this is probably not the route to take. So I
> thought maybe using the distribution properties of OpenAFS might be a
> better way. Are there any best practices for such a scenario?

The most likely scenario is a poorly configured file server.  Increase
the threads and the callbacks.

>=20
> On a different matter I experience that running the OpenAFS client on
> MS Windows turns out generally really, *really* slow.=20

Are you using the install out of the box?  96MB cache.  What work load
are you giving it?

> From my knowledge
> MS Windows simply isn't very good regarding file operations even on
> local disks in comparison to UNIX systems. But working with OpenAFS on
> MS Windows is even worse than the usual. When comparing the performance=

> between the Windows and the Linux OpenAFS clients I'm at least four
> times slower on Windows than on Linux. This can also be experienced
> during interactive work with the Windows client when operating on AFS.
> Question is if this is a known fact. Or if not so what I could do to
> relieve the problem.

The Windows implementation presently uses an SMB to AFS gateway to
access the AFS cache.  As a result the maximum throughput from the cache
is limited to 54MB/sec on 32-bit systems and 63MB/sec on 64-bit systems.
 Being able to reach that maximum requires a multi-core processor.  The
Windows client defaults to crypto on whereas the UNIX client defaults to
crypto off.  As a result, Windows is more secure but the communications
are slower.

In order to implement the Windows file access mode semantics, more RPCs
are required per file open on Windows than on UNIX.  If you are working
with a large number of small files this will become noticeable.

Jeffrey Altman


--------------enig4A821038F60D04D9DE323892
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iQEcBAEBAgAGBQJM3F1ZAAoJENxm1CNJffh4a2MH/ih+fyMtbr9/AfotFZDPA7VO
8hgdqtSFY7nhb6EACU/GWDrhj7hQe0gclBH+oPdfrCAJN8UAvW77UjAXFUChhKGb
5a3jlpfSXv54u24ucGYWfo+5oj6H8997ru3bGz3oEilm/TMi0FbGdqi6FqwkPVmz
vjn+B2YAywJH1N1SAMMQXGnvqxp46H2WvPomeIMyouu9yXml5XeS/auxV/RlXk23
q+t6rKRGormJ7gbki9b5mZ8IZX1qqHHTRx7m26gY14ILJnyKAY+6SWOCtYktQl7t
y+GLxfPvb+MKwUEtqR4O03VQ1mRWy0LlgPI/C76ky7fiEhxi2NAjndlFM3NgUTY=
=cC7B
-----END PGP SIGNATURE-----

--------------enig4A821038F60D04D9DE323892--