From: Eric Whiting <ewhiting@amis.com>
To: Fabrizio Nesti <nesti@medialab.sissa.it>
Cc: Neil Brown <neilb@cse.unsw.edu.au>, nfs@lists.sourceforge.net
Subject: Re: 2.4.20 TCP server + solaris client performance
Date: Fri, 07 Mar 2003 16:59:42 -0700 [thread overview]
Message-ID: <3E69326E.2AF0E6F2@amis.com> (raw)
In-Reply-To: Pine.GSO.4.40.0302201543110.1800-100000@bodoni
Neil/Fabrizio,
I'm still seeing the slow linux 2.4.20 nfs server when using a solaris client.
(as reported by Fabrizio Nesti <nesti@medialab.sissa.it> last month)
Summary: NFS operations related to the untar of a file are very/very slow on a
linux 2.4.20 NFS server (TCP and UDP). Bonnie streaming numbers look very good.
Just the file creation stuff is slow. 15 minutes instead of 2 minutes for the
tar -xf.
Is this an issue related to noac or sync options from the solaris client?
More benchmark data changing the test to highlight the problem.
I used 'time tar -xf linux-2.4.20.tar' for this testing.
eric
2.4.20 NFS server (TCP NFSV3 -- UDP numbers similar)
----------------------------------------------
0m 4s untar on local linux box (no sync included)
2m 18s Linux 2.4.19 NFS client (UDP)
15m 28s Solaris 2.7 NFS client (TCP)
26m 9s Solaris 2.9 NFS client (somewhat a traffic issue perhaps?)
NETAPPS NFS SERVER
-------------------
1m 19s Linux 2.4.20 client (UDP)
1m 54s Solaris 2.8 client
Fabrizio Nesti wrote:
>
> >I just tried your tar -xf cvs-1.11.5.tar test and I see numbers like yours
> > (except I don't see super fast solaris NFS numbers)
> > Client Server Time
> > -------------------------------------
> > solaris7 2.4.20 27.3
> > solaris7 solaris9 26.9
> > solaris9 solaris7 25.3
> > 2.4.18 2.4.20 7.0 (defaults to async mounts right?)
> > 2.4.20 2.4.18 15.1
> > linux local (no NFS) 1.2 (including sync)
>
> Hello, your third line is indeed strange to us.
> These are our times, in the full range of situations, still for tar xf.
> We'll try some other tests (dd and bonnie) tomorrow.
>
> Client Server Time (sec) TCP/UDP
> -------------------------------------------------------------------------
> 1) 2.4.18 solaris7 7 (rw=32k) (7 for rw=8k) T
> 2) solaris8 solaris7 8 (rw=32k) (15 for rw=8k) T
> 3) 2.4.18 solaris7 7 U
> 4) solaris8 solaris7 15 U
>
> 5) 2.4.18 2.4.20 (sync) 30 (rw=8k) T
> 6) 2.4.18 2.4.20 (async) 10 (rw=8k) T
> 7) solaris8 2.4.20 (sync) 55 (rw=8k) 60 (rw=1k) T
> 8) solaris8 2.4.20 (async) 40 (rw=8k) T
> 9) 2.4.18s 2.4.20 (sync) 15 U
> A) 2.4.18s 2.4.20 (async) 3 U
> B) solaris8 2.4.20 (sync) 53 U
> C) solaris8 2.4.20 (async) 34 U
>
> D) 2.4.18 2.4.18s (sync) 50 (both machines loaded) U
> E) 2.4.18 2.4.18s (async) 3 U
> F) solaris8 2.4.18s (sync) 87 (both machines loaded) U
> G) solaris8 2.4.18s (async) 33 U
>
> Local Writes (no NFS):
> 2.4.18s (Xeon server, RAID5/ext3) 2 (including sync)
> 2.4.18/20 (Athlon1900DDR test PC, ext3) 3 (including sync)
> solaris7 (E250 server, RAID5/UFS+logg) 3 (including sync)
>
> solaris8 client is an U10 (and has no retransmission problems).
>
> Comments:
> - TCP does not help the present linux server. (on the contrary for pure
> linux it's worse).
> - For pure solaris, wsize=32k doubles the TCP speed, otherwise comparable
> to UDP performance. We may try to enable it for linux also..
> - Does solaris default to async? (Strange, but there's no server side flag).
> If not, solaris is _very_ fast.
>
> --
> In other words, we switched from a SUN Enterprise250 to a quad Xeon (Dell),
> to find performance loss from case 2) to G). :(
>
> Hoping in the best,
> ciao,
> Fabrizio
>
> PS: Some nfsstat -m as seen from the solaris8 client.
>
> 1,2) solaris 7 server via TCP
> from didot:/export/backup
> Flags: vers=3,proto=tcp,sec=sys,hard,intr,link,symlink,acl,
> rsize=<....>,wsize=<.....>,retrans=5,timeo=600
> Attr cache: acregmin=3,acregmax=60,acdirmin=30,acdirmax=60
>
> 3,4) Solaris 7 server via UDP
> Flags: vers=3,proto=udp,sec=sys,hard,intr,link,symlink,acl,
> rsize=8192,wsize=8192,retrans=5,timeo=11
> Attr cache: acregmin=3,acregmax=60,acdirmin=30,acdirmax=60
> Lookups: srtt=7 (17ms), dev=3 (15ms), cur=2 (40ms)
> Reads: srtt=9 (22ms), dev=6 (30ms), cur=4 (80ms)
> Writes: srtt=7 (17ms), dev=3 (15ms), cur=2 (40ms)
> All: srtt=7 (17ms), dev=3 (15ms), cur=2 (40ms)
>
> 5,6,7,8) Linux server via TCP:
> Flags: vers=3,proto=tcp,sec=none,hard,intr,link,symlink,acl,
> rsize=8192,wsize=8192,retrans=5,timeo=600
> Attr cache: acregmin=3,acregmax=60,acdirmin=30,acdirmax=60
>
> 9,A,B,C,D,E,F,G) Linux servers via UDP
> Flags: vers=3,proto=udp,sec=none,hard,intr,link,symlink,
> rsize=8192,wsize=8192,retrans=5,timeo=11
> Attr cache: acregmin=3,acregmax=60,acdirmin=30,acdirmax=60
> Lookups: srtt=7 (17ms), dev=3 (15ms), cur=2 (40ms)
> Reads: srtt=7 (17ms), dev=4 (20ms), cur=2 (40ms)
> Writes: srtt=7 (17ms), dev=3 (15ms), cur=2 (40ms)
> All: srtt=7 (17ms), dev=3 (15ms), cur=2 (40ms)
>
> Client Server Time (sec)
> -----------------------------------------------
> TCP:
> 1) 2.4.18 solaris7 7 (rw=32k) (7 for rw=8k)
> 2) solaris8 solaris7 8 (rw=32k) (15 for rw=8k)
> 3) 2.4.18 2.4.20 (sync) 30 (rw=8k)
> 4) 2.4.18 2.4.20 (async) 10 (rw=8k)
> 5) solaris8 2.4.20 (sync) 55 (rw=8k) 60 (rw=1k)
> 6) solaris8 2.4.20 (async) 40 (rw=8k)
> UDP:
> 7) 2.4.18 solaris7 7.5
> 8) solaris8 solaris7 15
> 9) 2.4.18s 2.4.20 (sync) 15
> A) 2.4.18s 2.4.20 (async) 2.5
> B) solaris8 2.4.20 (sync) 53
> C) solaris8 2.4.20 (async) 34
>
> 9) 2.4.18 2.4.18s (sync) 50 (both machines loaded)
> A) 2.4.18 2.4.18s (async) 2.6
> B) solaris8 2.4.18s (sync) 87 (both machines loaded)
> C) solaris8 2.4.18s (async) 33
-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger
for complex code. Debugging C/C++ programs can leave you feeling lost and
disoriented. TotalView can help you find your way. Available on major UNIX
and Linux platforms. Try it free. www.etnus.com
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
next prev parent reply other threads:[~2003-03-07 23:59 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-02-17 17:36 2.4.20 TCP server + solaris client performance Fabrizio Nesti
2003-02-18 2:36 ` Alan Powell
2003-02-18 10:43 ` Fabrizio Nesti
2003-02-18 15:29 ` Eric Whiting
2003-02-18 15:47 ` Fabrizio Nesti
2003-02-19 4:39 ` Neil Brown
2003-02-19 11:30 ` Fabrizio Nesti
2003-02-19 14:07 ` Ion Badulescu
2003-02-19 15:27 ` Fabrizio Nesti
2003-02-19 15:47 ` Ion Badulescu
2003-02-19 16:54 ` Fabrizio Nesti
2003-02-19 17:56 ` Eric Whiting
2003-02-20 18:18 ` Fabrizio Nesti
2003-03-07 23:59 ` Eric Whiting [this message]
2003-03-17 17:13 ` [NFS] " Fabrizio Nesti
2003-06-05 14:49 ` Fabrizio Nesti
-- strict thread matches above, loose matches on Subject: below --
2003-02-18 17:35 Lever, Charles
2003-03-17 22:52 Wendy Cheng
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3E69326E.2AF0E6F2@amis.com \
--to=ewhiting@amis.com \
--cc=neilb@cse.unsw.edu.au \
--cc=nesti@medialab.sissa.it \
--cc=nfs@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox