All of lore.kernel.org
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: "Antti Tönkyrä" <daedalus@pingtimeout.net>
Cc: linux-nfs@vger.kernel.org
Subject: Re: Regarding client fairness
Date: Wed, 28 Mar 2018 11:47:54 -0400	[thread overview]
Message-ID: <20180328154754.GB3038@fieldses.org> (raw)
In-Reply-To: <4abd5e4f-2992-730b-8d44-5e611a3a2451@pingtimeout.net>

On Wed, Mar 28, 2018 at 06:35:53PM +0300, Antti Tönkyrä wrote:
> On 2018-03-28 17:59, J. Bruce Fields wrote:
> >On Wed, Mar 28, 2018 at 10:54:06AM -0400, bfields wrote:
> >>On Wed, Mar 28, 2018 at 02:04:57PM +0300, daedalus@pingtimeout.net wrote:
> >>>I came across a rather annoying issue where a single NFS client
> >>>caused resource starvation for NFS server. The server has several
> >>>storage pools which are used, in this particular case a single
> >>>client did fairly large read requests and effectively ate all nfsd
> >>>threads on the server and during that other clients were getting
> >>>hardly any I/O through to the other storage pool which was
> >>>completely idle.
> >>What version of the kernel are you running on your server?
> 4.15.10 on the system I am testing on.
> >I'm thinking that if it includes upstream 637600f3ffbf "SUNRPC: Change
> >TCP socket space reservation" (in upstream 4.8), then you may want to
> >experiment setting the sunrpc.svc_rpc_per_connection_limit module
> >parameter added in ff3ac5c3dc23 "SUNRPC: Add a server side
> >per-connection limit".
> >
> >You probably want to experiment with values greater than 0 (the default,
> >no limit) and the number of server threads.
> That helps for the client slowing down the whole server, thanks for
> the tip! Of course this doesn't help with the case of client
> accessing 2 different shares on the same server but that is
> something I can work around.

I thought the Linux client shared a single connection in that case, but
I could be wrong.

--b.

  reply	other threads:[~2018-03-28 15:47 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-28 11:04 Regarding client fairness daedalus
2018-03-28 14:54 ` J. Bruce Fields
2018-03-28 14:59   ` J. Bruce Fields
2018-03-28 15:35     ` Antti Tönkyrä
2018-03-28 15:47       ` J. Bruce Fields [this message]
2018-03-28 15:58       ` J. Bruce Fields
2018-03-28 16:49         ` Antti Tönkyrä

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=20180328154754.GB3038@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=daedalus@pingtimeout.net \
    --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.