From: Max Kellermann <max-hDT0AjmEH7RAfugRpC6u6w@public.gmane.org>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: linux-kernel@vger.kernel.org, linux-nfs@vger.kernel.org
Subject: Re: High load in 2.6.27, NFS / rpcauth_lookup_credcache()?
Date: Mon, 27 Oct 2008 10:58:43 +0100 [thread overview]
Message-ID: <20081027095843.GA10937@squirrel.roonstrasse.net> (raw)
In-Reply-To: <1224871763.22672.33.camel@localhost>
On 2008/10/24 20:09, Trond Myklebust <trond.myklebust@fys.uio.no> wrote:
> OK, could you please describe your environment a bit. Do you have lots
> of different users logged in at the same time, or do you perhaps use
> newgrp or su to switch uid/gids a lot on your processes?
> I'm trying to see if there might be a reason for the lookup in the
> credcache being such a heavy duty operation in your setup.
It's a web server for shared hosting. The web space is mounted via
NFSv3 from a NetApp. There is a huge number of web sites on this
cluster. All web sites are owned by the same UID, and the web server
runs as a different UID (read-only access).
Each time a CGI starts, its uid is changed to the one "owner" UID
(similar to mod_suexec, but there's only one UID for all customer
accounts). Each time a CGI starts, its chroot (pivot_root) is
constructed with several bind mounts (in a separate namespace with
CLONE_NEWNS).
There are no new users or groups being created. There are only 2 UIDs
accessing NFS: the webserver (ro) and CGI (rw).
Max
WARNING: multiple messages have this Message-ID (diff)
From: Max Kellermann <max@duempel.org>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: linux-kernel@vger.kernel.org, linux-nfs@vger.kernel.org
Subject: Re: High load in 2.6.27, NFS / rpcauth_lookup_credcache()?
Date: Mon, 27 Oct 2008 10:58:43 +0100 [thread overview]
Message-ID: <20081027095843.GA10937@squirrel.roonstrasse.net> (raw)
In-Reply-To: <1224871763.22672.33.camel@localhost>
On 2008/10/24 20:09, Trond Myklebust <trond.myklebust@fys.uio.no> wrote:
> OK, could you please describe your environment a bit. Do you have lots
> of different users logged in at the same time, or do you perhaps use
> newgrp or su to switch uid/gids a lot on your processes?
> I'm trying to see if there might be a reason for the lookup in the
> credcache being such a heavy duty operation in your setup.
It's a web server for shared hosting. The web space is mounted via
NFSv3 from a NetApp. There is a huge number of web sites on this
cluster. All web sites are owned by the same UID, and the web server
runs as a different UID (read-only access).
Each time a CGI starts, its uid is changed to the one "owner" UID
(similar to mod_suexec, but there's only one UID for all customer
accounts). Each time a CGI starts, its chroot (pivot_root) is
constructed with several bind mounts (in a separate namespace with
CLONE_NEWNS).
There are no new users or groups being created. There are only 2 UIDs
accessing NFS: the webserver (ro) and CGI (rw).
Max
next prev parent reply other threads:[~2008-10-27 9:58 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-22 9:12 High load in 2.6.27, NFS / rpcauth_lookup_credcache()? Max Kellermann
2008-10-22 9:12 ` Max Kellermann
[not found] ` <20081022091207.GA12996-2pNSKKP3PSJxEiad3KpGLI/oZP4lHnOC@public.gmane.org>
2008-10-22 17:56 ` J. Bruce Fields
2008-10-22 17:56 ` J. Bruce Fields
2008-10-23 12:36 ` Max Kellermann
2008-10-23 12:36 ` Max Kellermann
2008-10-23 14:55 ` Trond Myklebust
2008-10-24 8:39 ` Max Kellermann
2008-10-24 8:39 ` Max Kellermann
[not found] ` <20081024083913.GA15197-2pNSKKP3PSJxEiad3KpGLI/oZP4lHnOC@public.gmane.org>
2008-10-24 18:09 ` Trond Myklebust
2008-10-24 18:09 ` Trond Myklebust
2008-10-27 9:58 ` Max Kellermann [this message]
2008-10-27 9:58 ` Max Kellermann
[not found] ` <20081027095843.GA10937-2pNSKKP3PSJxEiad3KpGLI/oZP4lHnOC@public.gmane.org>
2008-10-27 15:48 ` Trond Myklebust
2008-10-27 15:48 ` Trond Myklebust
[not found] ` <1225122503.14242.12.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2008-11-17 12:35 ` Max Kellermann
2008-11-17 12:35 ` Max Kellermann
[not found] ` <20081117123536.GA16539-2pNSKKP3PSJxEiad3KpGLI/oZP4lHnOC@public.gmane.org>
2008-11-19 22:31 ` Trond Myklebust
2008-11-19 22:31 ` Trond Myklebust
[not found] ` <1227133861.28898.26.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2008-11-20 14:08 ` Max Kellermann
2008-11-20 14:08 ` Max Kellermann
2008-12-15 23:44 ` Harry Edmon
2008-12-15 23:44 ` Harry Edmon
[not found] ` <4946EBFA.60700-qmPYOCrcNLLyFCzt5hm0YvZ8FUJU4vz8@public.gmane.org>
2008-12-16 13:02 ` Trond Myklebust
2008-12-16 13:02 ` Trond Myklebust
[not found] ` <1229432553.7257.4.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2008-12-16 21:21 ` Willy Tarreau
2008-12-16 21:21 ` Willy Tarreau
[not found] ` <20081216212155.GA581-K+wRfnb2/UA@public.gmane.org>
2008-12-16 23:21 ` [stable] " Greg KH
2008-12-16 23:21 ` Greg KH
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=20081027095843.GA10937@squirrel.roonstrasse.net \
--to=max-hdt0ajmeh7rafugrpc6u6w@public.gmane.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=trond.myklebust@fys.uio.no \
/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.