Can you capture network traces then look at NFS protocol with
wireshark. Most optimal way for NFS client to work would be to issue
multiple WRITE requests, followed by a single COMMIT request for
all of those WRITE requests. If you see each WRITE followed by a COMMIT,
then this can introduce latenc
On Thu, 3 Dec 2015, Michael van Elst wrote:
reading with rsize=64k: ~ 90MB/s
reading with rsize=32k: ~ 60MB/s
writing with wsize=64k: ~ 40MB/s
writing with wsize=32k: ~ 30MB/s
Well, I have similar results except I get better performances while
reading/writing with {r,w}size=32k instead of 64,
i...@home.imil.net ("Emile `iMil' Heitor") writes:
>Now using NFS:
>$ dd if=/dev/zero bs=1024K count=1000 >Desktop/nfs@coruscant/imil/tmp/test
>1000+0 records in
>1000+0 records out
>1048576000 bytes (1.0 GB) copied, 51.8476 s, 20.2 MB/s
Best is to use TCP and 64k blocks. And there is a differe
On Thu, 3 Dec 2015, Emile `iMil' Heitor wrote:
[ 3] 0.0-10.0 sec 1.06 GBytes 908 Mbits/sec
1048576000 bytes (1.0 GB) copied, 9.27363 s, 113 MB/s
Gigabit link, all clear.
I've seen somewhat higher iperf results at around 998 MBit/s with Intel
server NICs. However, I consider anything above
On Thu, 3 Dec 2015, Emile `iMil' Heitor wrote:
I know, right? And yes results are identical with differents bs values.
I've tried a bazillion NFS options on the clients (TCP, UDP, {r,w}size from
8192
to 64k...), tried many OSes as a client, the NFS results are consistent,
always between 20 an
Continuing on the NAS performances topic, now it's NFS server's turn.
First things first, I've checked both network and disk throughput, neither cause
a bottleneck:
tatooine is the client
coruscant is the server
$ iperf -c coruscant -p 2828 -t 10
