All of lore.kernel.org
 help / color / mirror / Atom feed
From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: Carsten Aulbert
	<carsten.aulbert-l1a6w7hxd2yELgA04lAiVw@public.gmane.org>,
	linux-nfs@vger.kernel.org,
	Henning Fehrmann
	<henning.fehrmann-l1a6w7hxd2yELgA04lAiVw@public.gmane.org>,
	Steffen Grunewald
	<steffen.grunewald-l1a6w7hxd2yELgA04lAiVw@public.gmane.org>
Subject: Re: Massive NFS problems on large cluster with large number of mounts
Date: Wed, 02 Jul 2008 17:04:36 -0400	[thread overview]
Message-ID: <1215032676.7087.30.camel@localhost> (raw)
In-Reply-To: <20080702203130.GA24850@fieldses.org>

On Wed, 2008-07-02 at 16:31 -0400, J. Bruce Fields wrote:
> On Wed, Jul 02, 2008 at 04:00:21PM +0200, Carsten Aulbert wrote:
> > Hi all,
> > 
> > 
> > J. Bruce Fields wrote:
> > > 
> > > I'm slightly confused--the above is all about server configuration, but
> > > the below seems to describe only client problems?
> > 
> > Well, yes and no. All our servers are clients as well. I.e. we have
> > ~1340 nodes which all export a local directory to be cross-mounted.
> > 
> > >> (1) All our mounts use nfsvers=3 why is rpc.idmapd involved at all?
> > > 
> > > Are there actually files named "idmap" in those directories?  (Looks to
> > > me like they're only created in the v4 case, so I assume those open
> > > calls would return ENOENT if they didn't return ENFILE....)
> > 
> > No there is not and since we are not running v4 yet, we've disabled the
> > start for these on all nodes now.
> > 
> > 
> > > 
> > >> (2) Why is this daemon growing so extremely large?
> > >> # ps aux|grep rpc.idmapd
> > >> root      2309  0.1 16.2 2037152 1326944 ?     Ss   Jun30   1:24
> > >> /usr/sbin/rpc.idmapd
> > > 
> > > I think rpc.idmapd has some state for each directory whether they're for
> > > a v4 client or not, since it's using dnotify to watch for an "idmap"
> > > file to appear in each one.  The above shows about 2k per mount?
> > 
> > As you have written in your other email, yes that's 2 GByte and I've
> > seen boxes where > 500 mounts hung that the process was using all of the
> > 8 GByte. So I do think there is a bug.
> > 
> > OTOH, we still have the problem, that we can only mount up to ~ 350
> > remote directories. This one we think we tracked down to the fact that
> > the NFS clients refuse to use ports >1023 even though the servers are
> > exporting with the "insecure" option. Is there a way to force this?
> > Right now the NFS clients use ports 665-1023 (except a few odd ports
> > which were in use earlier).
> > 
> > Any hint for us how we shall proceed and maybe force the clients to also
> > use ports > 1023? I think that would solve our problems.
> 
> I think the below (untested) would tell the client to stop demanding a
> privileged port.

Alternatively, just change the values of /proc/sys/sunrpc/min_resvport
and /proc/sys/sunrpc/max_resvport to whatever range of ports you
actually want to use.

Trond


  reply	other threads:[~2008-07-02 21:04 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-01  8:19 Massive NFS problems on large cluster with large number of mounts Carsten Aulbert
     [not found] ` <4869E8AB.4060905-l1a6w7hxd2yELgA04lAiVw@public.gmane.org>
2008-07-01 18:22   ` J. Bruce Fields
2008-07-01 18:26     ` J. Bruce Fields
2008-07-02 14:00     ` Carsten Aulbert
     [not found]       ` <486B89F5.9000109-l1a6w7hxd2yELgA04lAiVw@public.gmane.org>
2008-07-02 20:31         ` J. Bruce Fields
2008-07-02 21:04           ` Trond Myklebust [this message]
2008-07-02 21:08             ` J. Bruce Fields
2008-07-03  5:31             ` Carsten Aulbert
     [not found]               ` <486C642B.3020100-l1a6w7hxd2yELgA04lAiVw@public.gmane.org>
2008-07-03 12:35                 ` Carsten Aulbert
2008-07-16  9:49             ` Carsten Aulbert
     [not found]               ` <487DC43F.8040408-l1a6w7hxd2yELgA04lAiVw@public.gmane.org>
2008-07-16 19:06                 ` J. Bruce Fields
2008-07-17  5:53                   ` Carsten Aulbert
     [not found]                     ` <487EDE57.4070100-l1a6w7hxd2yELgA04lAiVw@public.gmane.org>
2008-07-17 14:27                       ` J. Bruce Fields
2008-07-17 14:47                   ` Chuck Lever
     [not found]                     ` <76bd70e30807170747r31af3280icf0bd3fdbde17bac-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-07-17 14:48                       ` J. Bruce Fields
2008-07-17 15:11                         ` Chuck Lever
     [not found]                           ` <76bd70e30807170811s78175c0ep3a52da7c0ef95fc6-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-07-28 20:55                             ` Chuck Lever
     [not found]                               ` <76bd70e30807281355t4890a9b2q6960d79552538f60-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-07-29 11:32                                 ` Jeff Layton
     [not found]                                   ` <20080729073203.546a4269-RtJpwOs3+0O+kQycOl6kW4xkIHaj4LzF@public.gmane.org>
2008-07-29 17:43                                     ` Mike Mackovitch
2008-07-30 17:53                                 ` J. Bruce Fields
2008-07-30 19:33                                   ` Chuck Lever
     [not found]                                     ` <76bd70e30807301233t73f92775tbdeb3f8efbb34a4f-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-07-30 22:01                                       ` Chuck Lever
     [not found]                                         ` <76bd70e30807301501p5c0ba3c6i38fee02a1e606e31-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-08-15 20:34                                           ` Chuck Lever
     [not found]                                             ` <76bd70e30808151334i19822280j67a08b92b17582ba-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-08-15 20:47                                               ` Trond Myklebust
2008-08-15 21:04                                                 ` Trond Myklebust
2008-08-15 21:39                                                   ` Chuck Lever
2008-07-30 22:13                                       ` J. Bruce Fields
2008-07-31 16:35                                         ` Chuck Lever
2008-07-17 15:35                       ` Trond Myklebust

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=1215032676.7087.30.camel@localhost \
    --to=trond.myklebust@fys.uio.no \
    --cc=bfields@fieldses.org \
    --cc=carsten.aulbert-l1a6w7hxd2yELgA04lAiVw@public.gmane.org \
    --cc=henning.fehrmann-l1a6w7hxd2yELgA04lAiVw@public.gmane.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=steffen.grunewald-l1a6w7hxd2yELgA04lAiVw@public.gmane.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.