[SSSD] glibc |getgrouplist()|/|initgroups()| performace ... / was: Re: memory cache for initgroups
----- Original Message -----
From: "Simo Sorce" <ssorce(a)redhat.com>
To: "Niels de Vos" <ndevos(a)redhat.com>
Cc: sssd-devel(a)lists.fedorahosted.org, "Vijay Bellur"
<vbellur(a)redhat.com>
Sent: Thursday, November 6, 2014 11:32:53 PM
Subject: Re: [SSSD] memory cache for initgroups
On Thu, 6 Nov 2014 22:02:29 +0100
Niels de Vos <ndevos(a)redhat.com> wrote:
> On Thu, Nov 06, 2014 at 11:45:18PM +0530, Vijay Bellur wrote:
> > On 11/03/2014 08:12 PM, Jakub Hrozek wrote:
> > >On Mon, Nov 03, 2014 at 03:41:43PM +0100, Jakub Hrozek wrote:
> > >>On Mon, Nov 03, 2014 at 08:53:06AM -0500, Simo Sorce wrote:
> > >>>On Mon, 3 Nov 2014 13:57:08 +0100
> > >>>Jakub Hrozek <jhrozek(a)redhat.com> wrote:
[snip]
TBH this looks a little bit strange, other filesystems (as well as
the
kernel) create a credentials token when a user first authenticate and
keep these credentials attached to the user session for the duration.
Why does GlusterFS keeps hammering the system requesting the same
information again and again ?
Keep in mind that the use of getgrouplist() is an inherently costly
operation.
Is there any detailed breakdown which parts consume which amount of CPU time ?
Even adding caches, the system cannot cache for long because
it needs to return updated results eventually. Only the application
know when a user session terminates and/or the list needs to be
refreshed, so "caching" for this type of operation should be done
mostly on the application side.
BTW: What about using shared memory to transfer the groups data (basically reducing stuff
like |getgroups()| down to a atomic_refcount+shared_mutex_lock+|memcpy()|) ? It
doesn't bring much for small amounts of group entries but it scales much better when
the number of group entries becomes very large...
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) rmainz(a)redhat.com
\__\/\/__/ IPA/Kerberos5 team
/O /==\ O\
(;O/ \/ \O;)