On 01/29/18 17:40, Terry Barnaby wrote:

Now I understand that NFS's latency with writes is a performance bottleneck, but in
the past I have used the "async" mount option to good effect to minimise this. It
does not appear to have any effect on my systems. The "async" mount option is not
listed when you run "mount" to get a list of the mounts on the client. 

Pardon the brevity of this response.

I see pretty much the same numbers as you're seeing.  Sever and Client are both F27
and in my case both ends have SSD and the links are 1000Mb/s.

However, I'm not convinced the "issue" is related to write performance.  The reason I
say this is if do this on the client side

tar -zcf lin.tar f27k/linux-4.14.15/

meaning I'm reading from the server to create the tar.  The numbers were nearly
identical.  I think it may be more that the tar file has many (61337) files.  Most of
them rather small.

FWIW, I also performed the tests using vers=3 of nfs with slightly better numbers on
average.

_______________________________________________
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-leave@lists.fedoraproject.org

Thanks for the reply and trying. With your example its a bit different as you are creating the tar and compressing. The compression will take quite a lot of CPU and this is probably the bottleneck in your case.

If I un-tar directly on the servers disks in question (SATA hard drives software RAID-1) the untar takes 13 seconds rather than the NFS 3 minutes ...

time tar -xf linux-4.14.15.tar.gz -C /data/tmp
7.65user 4.87system 0:13.22elapsed 94%CPU (0avgtext+0avgdata 3404maxresident)k
305392inputs+1796584outputs (2major+311minor)pagefaults 0swaps
[terry@king nfs]$ sync
[terry@king nfs]$ rm -fr /data/tmp/linux-4.14.15
[terry@king nfs]$ sync
[terry@king nfs]$ make test1
sync; time (tar -xf linux-4.14.15.tar.gz -C /data/tmp; sync)

real    0m13.260s
user    0m7.652s
sys     0m4.914s