Timing file read/write over NFS

[Mark Komarinski]

On 12/18/2008 11:29 AM, Tom Buskey wrote:
>
>
> It seems like you're  looking in all the right places.
> I'd suggest running iozone (http://www.iozone.org).  That could help 
> you map the sweet spot for block size.  It will take awhile to run.
This.  Raising the MTU to 9000 and using larger block sizes will be a 
big benefit.

The larger MTU means that the CPU (and Ethernet cards) are not losing as 
much data to Ethernet overhead or building the packets.  Each packet is 
thus a bit more efficient than a 1500-byte packet.

The larger block size doesn't really relate to large files, so long as 
the block size is smaller than the file in question, there will be a 
point where the block size hits a sweet spot and then drops.  If most of 
your writes are to large files, then having a larger block size (and 
rsize/wsize) can help a lot.  Oh, and using noatime will help a lot.  
And nfsv4 instead of nfsv3.  Basically, set up a large number of tests, 
run iozone against it and see where you get good performance.  It's 
highly unlikely you'll get anywhere close to line speed, but if you can 
get an extra few MB/sec it's worth the time to test.
> I'd expect hdparm to be tied closely to PCs with IDE or SATA(?) 
> drives.  I know it won't work with SCSI drives on PCs..
Yes it does: SATA (and IDE I think) disks show up as /dev/sd? devices 
now.  But hdparm is more geared to work with block devices, so it 
doesn't really work with NFS mounts.

-Mark