[PVFS-users] Poor performance

[Nathan Poznick]

Thus spake Jon Combe:
> As an example I did "wc -l" on a file, on the PVFS file system that
> took 8 minutes 26 seconds. I then copied the same file to a disk
> mounted locally using the ext2 file system (/tmp) and ran the same
> command. It ran in 4 seconds, a massive increase in speed than on
> PVFS.

The 4 second number isn't realistic however.  Since you'd just copied
the file to local disk it was most likely fully or at least mostly
contained in the page cache.  Thus, a 4 second number in that situation
would be more like a scan through memory than across disk.

> It has been suggested by support staff that this is because PVFS is
> better at reading in large blocks and commands such as those I've
> listed typically request small blocks of data. They suggested solution
> was to pipe through dd using a large block size. So I tried this
> instead
> 
> dd if=myfile bs=16777216 | wc -l
> 
> That ran in 2 minutes 33 seconds, so quite a big increase in
> performance but still very very slow compared with the performance I
> get on the native local filesystem.

How big is this file?  Are there other things happening on the machine,
network-wise at the time?

> However I've been advised by support staff that I'll likely never get
> good performance from standard Unix commands running on files stored
> on the PVFS disks.

Most of the standard tools use quite small blocksizes, when compared to
what is optimal for PVFS.  wc for instance uses a 16k blocksize.  cp
uses the contents of the struct stat field st_blksize on the destination
filesystem (which for an ext2/3 filesystem is 4k).


-- 
Nathan Poznick <kraken at wang-fu.org>

Give a man a fish and you feed him for a day. Teach a man to fish and
you feed him for a lifetime. - Chinese Proverb

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://www.beowulf-underground.org/pipermail/pvfs-users/attachments/20050606/7f38bd37/attachment.bin