[nfsv4] NFSv4 performance issues on a lagged network

[Talpey, Thomas]

Soft mounts... why? Might want to add "intr" so they're killable btw.

I'm a little surprised the network stack is emitting ENETUNREACH here.
But if those occur and the mount is soft, it would account for a lot.
Personally I'd try to fix all three - use hard mounts fo testing, fix
the RPC socket error handling, and figure out why the error comes
up from the stack.

Back to my original motivation for the suggestion, one thing to play
with is the effect of changing the rpc slot table size. If the network
is flaky, but not fatally so, one result is that the rpc roundtrip time
increases by unpredictable amounts. This in turn means that the
client will run out of work to give the server (the default per-mount
slot table is 16 requests). Increasing the slot table may help.

Have you used Chuck's whizzo NFS python statistics gathering
script after these runs (before unmounting)? One really useful
thing they produce is operation latencies, and rpc backlog. They'd
be very interesting in this context. To me anyway. :-)
	<http://oss.oracle.com/~cel/linux-2.6/2.6.17/iostat-ms>

Good stuff, btw. May take a little while to digest.

Tom.

At 05:17 PM 8/29/2006, Bryce Harrington wrote:
>On Tue, Aug 29, 2006 at 04:56:48PM -0400, Chuck Lever wrote:
>> Hi Bryce-
>> 
>> Can Dipankar list his client's mount options in the report?
>
>Sure.
>
>Here is a typical example from one of the runs (#1650):
>
>  192.168.10.4:/ /mnt/192.168.10.4 nfs4 soft,noauto 0 0
>
>Iozone is called like this:
>
>  iozone -+q 1 -i 0 -i 1 -g 128M -Race -U /mnt/192.168.10.4 \
>    -f /mnt/192.168.10.4/iozone.tmp
>
>Other config files for a typical run can be found here:
>
>  Server:  http://crucible.osdl.org/runs/1650/sysinfo/nfs04.1/
>  Client:  http://crucible.osdl.org/runs/1650/sysinfo/nfs05.1/
>
>Bryce
>_______________________________________________
>NFSv4 mailing list
>NFSv4 at linux-nfs.org
>http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4