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.