[SSSD] RFC - disable the cleanup task by default

Jakub Hrozek jhrozek at redhat.com
Wed Apr 8 10:52:33 UTC 2015


On Wed, Apr 08, 2015 at 12:11:06PM +0200, Lukas Slebodnik wrote:
> On (08/04/15 11:59), Jakub Hrozek wrote:
> >On Wed, Apr 08, 2015 at 11:56:59AM +0200, Pavel Březina wrote:
> >> On 04/07/2015 05:08 PM, Jakub Hrozek wrote:
> >> >On Tue, Apr 07, 2015 at 05:02:33PM +0200, Jakub Hrozek wrote:
> >> >>On Tue, Apr 07, 2015 at 04:39:30PM +0200, Jakub Hrozek wrote:
> >> >>>So unless account_cache_expiration is set to something sensible, only
> >> >>>empty groups are removed and that's quite a corner case.
> >> >>
> >> >>Correction - also groups who have never logged in might be removed. This
> >> >                     ~~~~~~
> >> >                     users, sorry
> >> >>could be useful for pruning info after "ls -l" on directory like /tmp
> >> >>for example.
> >> >>
> >> >>But my opinion on the whole cleanup task still stands.
> >> 
> >> Sure we can disable it, it don't oppose.
> >> 
> >> Or we can also increase the default value for ldap_purge_cache_timeout to
> >> days instead of hours.
> >
> >This wouldn't help the biggest problem though which is when the cache cleanup
> >starts for a huge database on a busy server, the single transaction blocks
> >any other transaction..
> 
> Disabling clean-up task might help busy servers. There is hight probability
> all users/groups in sssd cache are used and refreshed very often
> 
> But could it cause problems in other use cases?

So far I can think of one use case:
    The users never log in and are only used for identity lookups. At
    the same time, the users on the server tend to change (be
    added/deleted). And at the same time, the removed entries are never
    requested (ie files are removed before someone does getpwuid() of
    the owner).

I can imagine ls -l on /tmp on a university server where students come
and go might hit this problem.

> 
> BTW we already have documented how to disable clean-up task.
> man sssd-ldap -> ldap_purge_cache_timeout

Noone reads documentation :-) We had two RHEL customer cases this week
where sssd_be was spinning out of control during a cleanup task and users
couldn't log in. For one customer (jb on #sssd), the sssd_be process was
even killed and restated.

> 
> maybe we should write wiki page with performance tuning.

In my opinion it would be better the other way around, add a wiki page
for cache size tuning. Disk space is cheap, but slow logins look bad.



More information about the sssd-devel mailing list