[SSSD] No negative cache with sssd_nss

Simo Sorce simo at redhat.com
Tue Jul 3 01:44:12 UTC 2012


On Tue, 2012-07-03 at 00:15 +0200, Jan Engelhardt wrote:
> On Wednesday 2012-06-27 14:53, Jan Engelhardt wrote:
> 
> >
> >On Tuesday 2012-06-26 17:43, Stephen Gallagher wrote:
> >>
> >>Actually, it most certainly is cached locally. If it was going to LDAP
> >>50,000 times, it would take you MUCH longer than 8.5s to get results
> >>back. Naturally, looking up results in a local file is faster than
> >>getting it out of the SSSD's cache database. However, we have sped this
> >>up considerably in SSSD 1.9.0 (currently in beta). We now maintain a
> >>second, in-memory cache for requests that is much faster than
> >>communicating across the socket to the sssd_nss process and then reading
> >>from the database (and processing group nested members).
> >>
> >>So if you wanted to test our latest nightlies with this program, I think
> >>you'd find it responding much faster.
> 
> Unfortunately not. The case is that the users/groups are not in passwd, 
> but in LDAP. top(1) shows that sssd_nss eats CPU like mad - which would 
> seem coherent with the assumption that it did not cache negative 
> entries.

The memory cache does not do negative caching indeed, but sssd_nss does,
however it caches negative entries for a very short period of time.

However in order to notice this you'd need to have a huge amounts of
unexisting entries you query in sequence.

> On the whole picture, I am trying out "bindfs", and how long it takes to 
> extract e.g. a kernel tarball with a given, but fixed over all test 
> runs, set of bindfs options. It's mostly about repeated getpw*/getgr* 
> lookups (at least one per created file).

Ah I see, you are paying the penalty for a full roundtrip to sssd_nss
for each file created. I think we can work on adding some negative
caching to the memory cache so to reduce from one call every file to one
call every 5 seconds or so.

Would you mind opening a ticket for it ?

Simo.

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




More information about the sssd-devel mailing list