[Bug 267631] slow nfs from FreeBSD kvm guest/client to linux kvm host/server

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267631

Rick Macklem <rmacklem@FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rmacklem@FreeBSD.org

--- Comment #6 from Rick Macklem <rmacklem@FreeBSD.org> ---
As you've noted, NFS performance issues are often
network interface related. However, here are a few
tunables you can try, beyond "readahead", which was
already mentioned. (And, yes, the man page is out of
date w.r.t. readahead. You can build a kernel from
sources with the value bumped up from 16, but I doubt
a value greater than 16 will be needed?)

First, do this on the client when the mount is established:
# nfsstat -m
This will show you what it is actually using.
You probably have NFSv3,TCP and an rsize of 64K or 128K.
If you stick "vfs.maxbcachebuf=1048576" in the client's
/boot/loader.conf, the rsize will probably go up to 1Mbyte.
(It will also recommend that you increase kern.ipc.maxsockbuf
 and will suggest a value. I'd increase it to at least the recommended
 value.)

A large rsize/wsize will have a similar effect to increasing
readahead, but will affect writing as well as reading.

nocto - Close to Open consistency will improve correctness
        when multiple clients access the same files. If your
        files are not being manipulated by multiple clients
        concurrently, turning it off can help.

Most 10Gbps net interfaces use multiple queues and pin a TCP
connection to a queue.  As such, an NFS mount with a single
TCP connection can only get a fraction of the bandwidth.
nconnect=N can help here, but it only works for NFSv4.1/4.2,
    so you also need to specify the "nfsv4" or "vers=4"
    mount option. (No idea w.r.t. VMs.)

Then there are all the cache timeouts "acdirmin,...".
Similar to nocto, longer timeouts have a negative impact
if other clients (or processes locally on the server) are changing
things. But longer timeouts result in better caching.

Then there is "noatime", since few care about the access time
being up to date.

However, nothing above will fix poor performance caused by a
poor net interface.

-- 
You are receiving this mail because:
You are the assignee for the bug.