[nfsv4] Performance drop in iozone for reading large files
Bryce Harrington
bryce at osdl.org
Fri Aug 25 17:32:52 EDT 2006
On Fri, Aug 25, 2006 at 05:13:23PM -0400, J. Bruce Fields wrote:
> On Fri, Aug 25, 2006 at 02:01:22PM -0700, Bryce Harrington wrote:
> > Does anyone have an idea why the dropoff is occuring? Is the memory
> > size expected to affect NFS performance this way?
>
> Yes, definitely; it can answer the reads out of the client's cache, as
> long as the file is small enough to fit in the client's memory.
>
> (What exactly is it testing in this case? I don't really know what
> iozone does. Bad me.)
For each file size and record length, it does the following:
* Write a file of that size to the server
* Re-write it
* Read a file of that size from the server
* Re-read it
Here's two cycles from the raw log:
KB reclen write rewrite read reread
131072 512 31048 33882 64771 65143
1048576 512 31620 14321 18157 25666
The units for the first two columns is kB, the rest are kB/sec.
In the first case, with a file 10% the size of memory, write and
rewrite are nearly identical, as are read and reread.
In the second case, where the file is about the size of available
memory, write performance is unaffected but rewrite performance drops by
over half (shouldn't it be going up, not down in this case if it can
cache?) Read performance drops by more than two thirds, although we do
see some benefit (presumably from caching?) in the reread case.
As far as I understand from how iozone works, the read and write cases
should not be subject to caching, but I could be wrong... We could ask
Don Capps for interpretation if it might help.
Bryce
More information about the NFSv4
mailing list