<div dir="ltr"><div><div>NFS read performance is primarily client-driven.  usually setting the read-ahead (for example, mount_nfs -a 4) is the biggest performance driver for reads.  OpenBSD defaults to -a 1 which is basically no read-ahead.  I suggest -a 4 at a minimum.  Also make sure the read block size is at least 8192 (which is the default).  Bumping it higher should theoretically work but see next paragraph.  32768 is reasonable for TCP.  65536 is a bit excessive (if it fails completely then the TCP buffers are not being sized properly and the NFS protocol implementation is probably deadlocking due to the TCP buffer filling up, or due to insufficient TCP buffer space).<br><br></div>In terms of streaming reads over TCP, it should be possible to stream at the full network bandwidth (~90-100 MBytes/sec) as long as the implementation creates the TCP connection properly.  The TCP buffers have to be made relatively large (I would suggest at least 1MB rx and tx buffers), the TCP connection must also use window scaling and must also be sure to use TCP_NODELAY.  Otherwise performance will be horrible.   You might need to enlist one of the devs to check these parameters, there are often quite a few knobs to turn to tune it properly and defaults were set very low historically.<br><br></div><div>NFS write performance is harder.  With a NFSv3 mount (make sure the mount is NFSv3 and not v2) getting good performance depends almost entirely on the client-side implementation doing a proper streaming two-phase commit.  A larger buffer size helps too (32768 is reasonable for TCP).  So I can't make any suggestions there.  A larger TCP buffer may help though (again, at least a ~1MB TCP buffer is recommended).  The DFly server side won't be a bottleneck for either reads or writes.<br><br>--<br><br></div><div>When testing read performance be sure to take into account server-side caching.  A freshly booted server will have to read the file from storage which with a hard drive might have limited bandwidth (e.g. ~70MB/sec).  On a remount (umount/mount) to clear the client-side cache, the second run the file will be fully cached and the read test will be testing purely network bandwidth (e.g. ~90-100 MB/sec).  If no client-side remount occurs then on a second or later run some of the data may already be on the client and result in no network transaction at all (giving very high perceived but test-incorrect results).<br><br>With read-ahead and proper TCP settings the entire data path should be able to stream at nearly full bandwidth uncached (for whatever the bw limiter is, network or disk).<br></div><div><br></div>-Matt<br><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 21, 2016 at 6:11 PM, Predrag Punosevac <span dir="ltr"><<a href="mailto:punosevac72@gmail.com" target="_blank">punosevac72@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This is a very interested thread. I just played little bit with dd on my<br>
desktop machine running OpenBSD 5.9 amd64 NFS-client. NFS server runs on<br>
DragonFly BSD 4.4.2. No optimization of any kind has been done. My home<br>
network is 1 Gigabit. I will play over the weekend with various block<br>
sizes and try to use iozone to get something more interesting.<br>
<br>
UDP mount<br>
<br>
write: 17.014003 MB/s<br>
read: 22.397014 MB/s<br>
<br>
TCP mount:<br>
<br>
write: 9.338817 MB/s<br>
read: 20.47062 MB/s<br>
<br>
Best,<br>
Predrag<br>
<br>
P.S. Yes under the NFS DF is using HAMMER so I am able to get history,<br>
snapshot, and all that nifty stuff.<br>
</blockquote></div><br></div>