On 30/01/18 00:32, Ed Greshko wrote:
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(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)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