All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Staubach <staubach@redhat.com>
To: Neil Horman <nhorman@redhat.com>
Cc: Anthony Howe <ahowe_ca@yahoo.ca>, nfs@lists.sourceforge.net
Subject: Re: slow file opens on nfs mount across high-latency network
Date: Wed, 29 Jun 2005 08:33:16 -0400	[thread overview]
Message-ID: <42C2950C.2070705@redhat.com> (raw)
In-Reply-To: <20050629120445.GB6865@hmsendeavour.rdu.redhat.com>

Neil Horman wrote:

>On Tue, Jun 28, 2005 at 11:30:17AM -0400, Anthony Howe wrote:
>  
>
>>I have searched through the mail lists and google and
>>have not found material describing the nfs file open
>>threshold effect that I am experiencing.  
>>
>>I have been experimenting with opening files on NFS
>>mounts over varying network latencies.  I notice that
>>there seems to be a threshold on the number of
>>concurrent nfs file opens as network latency
>>increases.  Up to and including the threshold, nfs
>>file open performance is fine.  After the threshold of
>>concurrent opens, performance degrades at a linear
>>rate.
>>
>>For example, the graph in the attached files shows
>>this threshold effect for various network latencies:
>>- 0ms network latency - no max limit
>>- 20ms network latency - 40 maximum concurrent opens
>>- 40ms network latency - 20 maximum concurrent opens
>>- 80ms network latency - 15 maximum concurrent opens
>>- 120ms network latency - 5 maximum concurrent opens
>>
>>What would cause this "hockey stick" threshold effect
>>shown in the attached file?
>>Are there any settings that would change this effect?
>>
>>Here are the stats of my experiment:
>>- testing using Redhat Enterprise AS servers V3
>>connected via a 100Mbps switch
>>- inserting latency with nist net
>>- experiment process spawns X number of threads set to
>>each open a file on an NFS mount, the time taken for
>>each file open is recorded
>>- adjusting rsize, wsize does not affect "hockey
>>stick" threshold effect
>>- adjusting /proc/sys/net/core/rmem* does not affect
>>"hockey stick" threshold effect
>>- adjusting number of nfsd processes does not affect 
>>"hockey stick" threshold effect
>>
>>Thanks in advance for any tips or directions where I
>>can look for more information on this topic.
>>
>>Regards,
>>
>>Anthony Howe
>>
>>__________________________________________________
>>Do You Yahoo!?
>>Tired of spam?  Yahoo! Mail has the best spam protection around 
>>http://mail.yahoo.com 
>>    
>>
>
>
>do you have tcpdumps taken at all these data points?  It kind of sounds to me
>like your getting a geared slowdown from additional congestion caused by rpc
>retransmits (i.e., on a high latency link, you'll wind up with more rpc
>retransmits, resulting in more congestion, resulting in more lost packets,
>resulting in more retransmits, etc.).
>
Some questions --

These are mounts done using the NFSv3 protocol?  Over TCP or over UDP?

Each thread is opening an independent file?  In independent directories
or in a common directory?

    Thanx...

       ps


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

  reply	other threads:[~2005-06-29 12:36 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-28 15:30 slow file opens on nfs mount across high-latency network Anthony Howe
2005-06-29 12:04 ` Neil Horman
2005-06-29 12:33   ` Peter Staubach [this message]
2005-06-29 13:43     ` Anthony Howe
2005-07-06 19:16     ` Anthony Howe
2005-06-29 13:56 ` Trond Myklebust
  -- strict thread matches above, loose matches on Subject: below --
2005-07-06 19:21 Lever, Charles
2005-06-28 16:53 Anthony Howe
2005-06-27 23:53 Anthony Howe

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=42C2950C.2070705@redhat.com \
    --to=staubach@redhat.com \
    --cc=ahowe_ca@yahoo.ca \
    --cc=nfs@lists.sourceforge.net \
    --cc=nhorman@redhat.com \
    /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.