[OpenAFS] Server disk operations speed

[jukka.tuominen@finndesign.fi]

> On Sunday 07 April 2013 20:55:41 jukka.tuominen@finndesign.fi wrote:
>
>> So, I thought that the network communication was the bottle neck, but
>> just
>> in case I tested whether it's the server itself that was somehow
>> exceptionally slow. I copy/pasted the earlier mentioned test directory
>> (see the full message below) first in the normal unix environment
>> /home/user/...(source and target), which turned out to be extremely fast
>> (HW supported virtualization on a SSD disk). So, no problem there.
>
> Check the I/O scheduler settings on your virtual machine and on the
> server.
> The default cfq is not the fastest for this usecase. Especially if you are
> using a battery backed hw raid you may test both set to noop.

Where can I find that? I'm currently using Virtualbox, although I have
previously used VMWare Server. I also use some HW clients. I have tested
the server on HW earlier, too, but none have solved the magnitude problem.
That's why I returned to virtualization, because it's otherwise much more
convenient in development phase.

>
> You are testing the worst case for your setup:
> Disk I/O and network I/O is very expensive for virtualization. Also if you
> are
> using paravirtualization the overhead is noticeable.
>
> Copy at /home means you only have the disk I/O overhead for writing (guess
> all
> 300MB are already in cache and there is no need for synchronous write
> operations).
>
I understand that, but for the magnitude check it gave a rough result. For
the eventual fine-tuning I'll be more careful.


>> Then I got access to an afs account on the same machine (kinit; aklog),
>> and copied the same test directory in /afs/cell/user/...(source and
>> target) which turned out to be extremely slow.
>
> For afs:
> Also if the data are already in cache the client has to check if the files
> or
> permissions did not change meanwhile on the server. so you get network I/O
> for
> each file and probably disk I/O for the client disk cache.
> The client copies each file which will lead to disk I/O on the client disk
> cache, network I/O for client and server and disk I/O for the server. The
> disk
> I/O most probably includes lots of synchronous operations...

I duplicated the directory within the same parent directory. The
permissions shouldn't cause any extras, and since I'm concerned about both
the reading and writing speed, both were needed. Cache should give rather
unrealistically fast figures, but until the numbers get actually high, I
don't give them too much attention.

>
> Using a afs client on the fileserver is most probably slower than on
> another
> client in your network.

Good to know.

> Also try to use memcache on the client for the test!

Hmmm... For some reason, I can't seem to turn the memcache on, on my
client machine. Other parameters work, but with -memcache it halts on
(GDM) login.

>
>> I did try to optimize the fileserver parameters, but I could only gain
>> like 30-40% improvement. I believe there is some bigger issue to be
>> solved
>> first. I wonder if anybody else has had a similar issue, or if you could
>> think of any possible causes for this sort of symptons?
>
> For us AFS performs mach faster on small files than our cluster filesystem
> MooseFS which we are using in parallel. AFS is something like 20-30 times
> faster for small files... (tested with 40905 Files of total 444.47 MB)
>
> We also use AFS fileserver with ssd for our small $HOME volumes but
> without
> virtualization. For other fileservers (mainly hosting volumes with bigger
> files) we use xen with paravirtualization which is noticeable slower.
>
> --
> Markus Koeberl
> Graz University of Technology
> Signal Processing and Speech Communication Laboratory
> E-mail: markus.koeberl@tugraz.at
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
>

Good to know, thank you!

br, jukka