All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul Smith" <pausmith@nortelnetworks.com>
To: nfs@lists.sourceforge.net
Subject: Re: NFS client write performance issue ... thoughts?
Date: 12 Jan 2004 16:37:13 -0500	[thread overview]
Message-ID: <vpdrbrp8j1bq.fsf@lemming.engeast.baynetworks.com> (raw)
In-Reply-To: <32997.141.211.133.197.1073683824.squirrel@webmail.uio.no>

Thanks Trond.

We tried out your patch and it did really make a difference in terms of
both the nfsstat numbers (or, Ethereal in this case) AND the performance
the user sees, at least from a ClearCase perspective (gnurr.diff is with
your patch):

> This time, I used my desktop box (running 2.4.18-27.7.x + gnurr.diff)
> as view server, while running the small build on a different Linux box.
> I captured NFS traffic with Ethereal, so as to rule out any possible
> accounting errors in nfsstat.  Here's what the numbers look like:
> 
>            nopatch  gnurr.dif    gnurr.diff     Solaris
>             UDP/4K     UDP/4K       UDP/32K     TCP/32K
>            -------  ---------    ----------     -------
>     WRITE    65017       1298           538         612
>     COMMIT   29268        994           882           7
>     LOOKUP    1082       1020          1016        1986
>     GETATTR    548        490           404         532
>     READ       480         75            89           0
>     FSSTAT      60          3             3          60
>     FSINFO      60          3             3           0
>     REMOVE      19         15             8         291
>     ACCESS       0          0             0         291
>     NULL        10          6             5           0
>     SETATTR      4          2             3           2
>     RENAME       4          2             3           2
>     CREATE       4          2             3           2
>     ======   =====       ====          ====        ====
>     Total    96556       3910          2957        3785
> 
>     CPU        85s        85s           85s         85s
>     Elapsed   202s       121s          121s        139s
> 
> Bytes read: 1.97MB      0.3MB         0.7MB          ??
> Bytes writ: 90.3MB      5.2MB         4.9MB          ??
> 
> The Solaris numbers are from the same capture I did a few days ago.
> For the build times, all builds were done on a machine in our Linux
> pool (which was not patched), using my desktop in various
> configurations as view server.  For the Solaris view server, I used a
> Sun Ultra-80 running Solaris 8.  CPU use was that used by the build
> itself, not the view server, so we'd expect it to be constant.
> 
> So Linux with the gnurr.dif patch stacks up pretty well against Solaris.
> Note that there are no numbers here for Linux with TCP mounts.  That's
> because I was analyzing the data with ethereal, and it often can't
> find the RPC boundaries properly when TCP is in use, so the numbers
> are meaningless.
> 
> One noticable difference between Linux and Solaris is that Linux
> generates a lot more COMMITS than Solaris.

However, then we discovered something concerning, so we are not using
the patch as-is right now, at least pending further investigation:

> Oops.  With this patch applied, I didn't see a problem when using
> my desktop as view server, but when I use it to do builds on, I'm
> occasionally seeing the following:
> 
>   ldsimpc: final link failed: Message too long
> 
> Ldsimpc is the GNU linker built as a cross-linker for VxSim (ie: for
> MinGW).  The linker is getting EMSGSIZE somehow, and at this point, I
> can only guess that it's getting it on a call to write().  Probably NFS
> is trying to write an overly large UDP packet to the server.  This is
> with UDP mounts and rsize=wsize=4KB.  Write failures are a little scary,
> so I think I'm going to back out this patch for now.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <psmith@nortelnetworks.com>   HASMAT--HA Software Mthds & Tools
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.


-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

  reply	other threads:[~2004-01-12 21:37 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-09 21:30 NFS client write performance issue ... thoughts? trond.myklebust
2004-01-12 21:37 ` Paul Smith [this message]
  -- strict thread matches above, loose matches on Subject: below --
2004-01-12 12:45 Mikkelborg, Kjetil
2004-01-12 17:30 ` Paul Smith
2004-01-08 17:32 trond.myklebust
2004-01-08 17:47 ` Paul Smith
2004-01-08 17:48 ` trond.myklebust
2004-01-07 20:50 Lever, Charles
2004-01-06 16:17 Lever, Charles
2004-01-06 18:10 ` Paul Smith
2004-01-06  4:34 Trond Myklebust
2004-01-06  6:33 ` Paul Smith
2004-01-05 22:11 Paul Smith
2004-01-08 15:26 ` Paul Smith

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=vpdrbrp8j1bq.fsf@lemming.engeast.baynetworks.com \
    --to=pausmith@nortelnetworks.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.