linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dean <seattleplus@gmail.com>
To: Cedric Blancher <cedric.blancher@gmail.com>,
	Jim Rees <rees@umich.edu>,
	Trond Myklebust <trond.myklebust@primarydata.com>
Cc: Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: Tuning Linux NFSv4 for high latency connections?
Date: Sun, 27 Apr 2014 22:23:26 -0700	[thread overview]
Message-ID: <535DE5CE.7050600@gmail.com> (raw)
In-Reply-To: <CALXu0UdsUk2bSWUzOXLHJ1FKtnZMyo0OHJSj=0hQpwwHVu52zw@mail.gmail.com>



On 4/24/14, 10:22 AM, Cedric Blancher wrote:
> On 24 April 2014 05:12, Jim Rees <rees@umich.edu> wrote:
>> Cedric Blancher wrote:
>>
>>    Are there any options to improve the Linux NFSv4 performance over a
>>    high latency connection?
>>
>> We did some work along these lines at CITI years ago. As I remember, the
>> main thing was to increase net.ipv4.tcp_[rw]mem on the server side, because
>> tcp auto-tuning was being defeated. This may be less of an issue with your
>> work load, which sounds like many small files rather than one big one.  In
>> theory, NFSv4 delegations should help, but I don't know how well that works.

Along with Jim's work, we followed up with a fair bit, but in general we 
found that nfs clients just can't do well over large rtt due to the slow 
window ramp up time and adverse reaction to packet loss.  Unfortunately 
the only way to overcome these issues (other than using a custom udp 
protocol which isn't supported) is to use multiple TCP connections, 
which is what we do by  using multiple nodes....

I have some basic instructions here on what we do in our environments:
http://researcher.watson.ibm.com/researcher/view_person_subpage.php?id=4427

Dean

  reply	other threads:[~2014-04-28  5:23 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-23 18:01 Tuning Linux NFSv4 for high latency connections? Cedric Blancher
2014-04-23 20:24 ` Malahal Naineni
2014-04-23 20:30   ` Cedric Blancher
2014-04-23 20:44     ` Malahal Naineni
2014-04-23 21:04       ` Cedric Blancher
2014-04-23 21:15         ` Malahal Naineni
2014-04-23 22:14           ` Cedric Blancher
2014-04-23 22:57             ` Malahal Naineni
2014-04-24  3:12 ` Jim Rees
2014-04-24 17:22   ` Cedric Blancher
2014-04-28  5:23     ` Dean [this message]
2014-04-28 10:35       ` Jim Rees

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=535DE5CE.7050600@gmail.com \
    --to=seattleplus@gmail.com \
    --cc=cedric.blancher@gmail.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=rees@umich.edu \
    --cc=trond.myklebust@primarydata.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).