Heads Up: default NFS server changing to the new one
rmacklem at uoguelph.ca
Mon Jun 6 13:08:24 UTC 2011
Chris Forgeron wrote:
> I hope to do a speed test comparison between new and old NFS servers
> this weekend - At this stage, my feeling is that the new NFS server is
> at least as fast. I suspect tests will show it to be faster (at least
> the code looks faster. :-) ).
Well, I doubt you'll find much difference performance wise. An NFS
server can be looked as a protocol translator, converting the NFS RPCs
into VFS/VOP calls. Performance is largely defined by how well the network
stack and/or file system perform.
When you set up a server, there are a few things that may help:
- If you are using FFS, create the file systems with the largest block
- If you are using ZFS, I know diddly about it, but others have suggested
moving the ZIL log to a dedicated device which can do fast writes, such
as an SSD optimized for fast write performance (not all SSDs do fast writing,
although I think choosing the size of it significantly larger that the
size of the log, so it has a lot of free blocks may help?).
- Use lottsa nfsd threads (the default of 4 is for very minimal nfs serving
Others may have additional suggestions?
As for things the nfsd server code can do, I plan on looking at a couple
of things, but I don't think those will be in 9.0:
- Making MAXBSIZE larger. Even if it is larger than the largest block
size supported for the underlying fs, this may help, because it can
reduce the # of I/O RPCs.
- A small patch (I'll probably make it available to anyone who wants to
test it once I've done so) that will allow some NFS RPCs to use shared
vnode locks. This should allow for more parallelism of read operations
on a file, such as read-aheads done by a client. (I recently added a
lock flags argument to VFS_FHTOVP() for 9.0, to facilitate this.)
--> This one might improve the VFS/VOP call side.
Thanks for letting me know how it's going, rick
More information about the freebsd-current