All of lore.kernel.org
 help / color / mirror / Atom feed
From: mcr@sandelman.ca
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>
Subject: Re: big send queues on NFS server
Date: Tue, 18 Jun 2013 15:32:04 -0400	[thread overview]
Message-ID: <15556.1371583924@sandelman.ca> (raw)
In-Reply-To: <20130618172530.GB9915@fieldses.org>


On Tue, Jun 18, 2013 at 09:48:31AM -0400, mcr@sandelman.ca wrote:
    >> Hi, I have been an NFS user and enthusiast for 20+ years.  My home
    >> systems still have the numerical uid that doe.carleton.ca assigned me
    >> back in 1989... cause of NFS...  Recently, I turned off a NetBSD 5

...

    >> If they decline in time, there is no interruption, otherwise, the web
    >> server gets an underrun, and the music stops.
    >> 
    >> I could also capture the entire NFS stream, or just do TCP window
    >> analysis on this stream, but I would suspect that it's a problem on
    >> the client.

J. Bruce Fields <bfields@fieldses.org> wrote:
    jb> Could be, though it sounds like all you changed here was replacing
    jb> the NetBSD server by a Linux server?

well, I mentioned NetBSD to indicate the length of time I have used various
NFS systems, not because I felt that it was a specific interop issue.

    jb> Of course, that's a rather complicated change in itself (default NFS
    jb> version, transport (tcp vs udp), etc. may have changed as well.

    jb> Might be worth fooling with those parameters using mount options.
    jb> The defaults should be best, but it might help narrow down the
    jb> problem.

I am using mostly  default options: nosuid, nodev, hard.
Generally, I have solved problems in the past by going back to NFSv3 on UDP
mounts, and then doing the classic nfsd worker tuning dance, and the
rsize=/wsize= game.   

I am posting to understand if someone says, "oh, yes, you found issue 34534,
and it's a client side problem, and it's fixed in 3.7.2..."
or: "thats is weird.  What does /proc/nfs/magic_client_side_tunnable say?"
or: "I have that too"
or: "can you send a pcap?"

I would love: "that's a client problem" vs "that's a server problem",
and I'd go investigate deeper there :-)

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [ 
	

      reply	other threads:[~2013-06-18 19:33 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-18 13:48 big send queues on NFS server mcr
2013-06-18 17:25 ` J. Bruce Fields
2013-06-18 19:32   ` mcr [this message]

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=15556.1371583924@sandelman.ca \
    --to=mcr@sandelman.ca \
    --cc=bfields@fieldses.org \
    --cc=linux-nfs@vger.kernel.org \
    /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.