[SSSD] memory cache for initgroups

Jakub Hrozek jhrozek at redhat.com
Mon Nov 3 14:42:07 UTC 2014


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 at redhat.com> wrote:
> > 
> > > Hi,
> > > 
> > > we had short discussion on $SUBJECT with Simo on IRC already, but
> > > there are multiple people involved from multiple timezones, so I
> > > think a mailing list thread would be better trackable.
> > > 
> > > Can we add another memory cache file to SSSD, that would track
> > > initgroups/getgrouplist results for the NSS responder? I realize
> > > initgroups is a bit different operation than getpw{uid,nam} and
> > > getgr{gid,nam} but what if the new memcache was only used by the NSS
> > > responder and at the same time invalidated when initgroups is
> > > initiated by the PAM responder to ensure the memcache is up-to-date?
> > 
> > Can you describe the use case before jumping into a proposed solution ?
> 
> Many getgrouplist() or initgroups() calls in a quick succession. One
> user is GlusterFS -- I'm not quite sure what the reason is there, maybe
> Vijay can elaborate.

Sorry, I forgot to CC Vijay.

> 
> The other use-case is slapi-nis that calls getgrouplist() -- Alexander
> would explain better here, I only know that slapi-nis uses
> getgrouplist() during memberUID processing, but I'm fuzzy on the
> details.
> 
> > 
> > > I already know about two projects that would benefit from faster
> > > initgroups operation - GlusterFS uses getgrouplist() quite a lot with
> > > some setups and also in the IPA server mode, the SSSD running on the
> > > server becomes a bit of a bottlenec for some operations.
> > 
> > Is the problem related to accessing the main ldb cache, or the fact we
> > also go out and contact the IdM server ?
> 
> Mostly the cache. In particular, with the GlusterFS case, there was a
> huge filesystem directory that triggered 4000+ getgrouplist() calls, one
> per a file. Even though the getgrouplist() calls were for fewer than 10
> users, we would hit LDB every time and that produced quite a load on the
> SSSD.
> 
> > 
> > > Are there any technical reasons against a new memcache file that would
> > > cache initgroups?
> > 
> > The main reason would be potential inconsistency between this cache and
> > the users and groups caches, but I do not think that would be really a
> > big deal if there is a pretty good reason for the cache.
> 
> Hm, I see, then we have the same information duplicated in two caches,
> just from a different angle. However, for cases where precision really
> matters (access control), we don't use these caches anyway.
> 
> Could we mitigate this problem by invalidating the memcache when group
> membership changes at all during a backend operation? I think changes to
> LDAP object are so rare, that invalidating the memcache (which is quite
> shortlived anyway) would be worth it.
> 
> > 
> > Do we need to insure all groups are resolvable in the groups cache ?
> 
> I don't think so, if the group is not in the groups cache, then we just
> hit the responder.
> 
> > Or is it ok if gids returned by the getgrouplist are not immediately
> > available in the groups cache ?
> > What about the user ?
> 
> I *think* the user could also be left out. If the application also needs
> user data, it simply calls getpwnam -- like id(1) does. getgrouplist is
> a different interface with different outputs.
> 
> > 
> > Simo.
> > 
> > -- 
> > Simo Sorce * Red Hat, Inc * New York



More information about the sssd-devel mailing list