1:03 p.m.
On 9/18/18 12:58 PM, Kropelin, Adam wrote:
NFSv4.0, nolock:
10.2.145.170:/test on /home/ec2-user/mnt type nfs4
(rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.3.98.13,local_lock=none,addr=10.2.145.170)
Try V4.1. V4.0 is only best effort, but not performance. V3 we try
not to break entirely.
Also, you are overriding the read and write sizes. It shouldn't be
terribly surprising that there's not enough buffer space. We're not
allocating that much memory.
To be fair, the system was never fully async.
Especially in Ganesha V2.5. A lot of the async I-O code didn't go in
until V2.6. I merely wrote it against V2.3. It took a long time to
be integrated.
Note I mentioned that a predecessor had decided upon writev(). All
I've done is work around it. Repeatedly. Don't blame the messenger.
(That old code wouldn't even pass pynfs. So you're welcome.)
Maybe someday somebody will let us use sendmmsg(). It's available on
FreeBSD now, too.
Also, weighted fair queuing. Because we actually knew a few things in
the early '90s....
Piggy indeed. [...] A server needs to cope with clients doing things
that aren't always optimal.
Nope. The server needs to STARVE clients that aren't optimal. That's
also the philosophy in the kernel TCP and net stack. And pretty much
every router and switch in the network path.
If you send 10 Gbps into a switch with a typical 4 way memory, and
your target is 1 Gbps, you will stall. (Called head of line block.)
Because the most you can drain is 3 Gbps on the other 3 links.
That's why high performance routers move everything off to separate
cards. Usually each with 3 or 4 interfaces.
Use reasonably sized requests and wait your turn. That will give the
best overall aggregate performance for all clients.