[SSSD] memory cache for initgroups

Simo Sorce ssorce at redhat.com
Mon Nov 3 14:50:04 UTC 2014


On Mon, 3 Nov 2014 15:41:43 +0100
Jakub Hrozek <jhrozek at redhat.com> 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.
> 
> 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.

Probably sufficient, what is the expected lifetime of the initgroups
memcache ?

> > 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.

ok

> > 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.

fine then.

Note that one option could be to extend the user's cache, to have a
list of gids on the tail of the user's data, I am too stuffed of
medications though to think clearly if that is a good idea or a
colossal idiocy :-)

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York



More information about the sssd-devel mailing list