Linux NFS development
 help / color / mirror / Atom feed
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

  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