[SSSD-users] SSSD with 389DS

Lukas Slebodnik lslebodn at redhat.com
Thu Jan 16 11:09:44 UTC 2014


On (16/01/14 12:06), Jakub Hrozek wrote:
>On Thu, Jan 16, 2014 at 11:29:53AM +0100, Mitja Mihelič wrote:
>> Hi!
>> 
>> We are running a CentOS6 server using SSSD that connects to 389DS
>> containing 70k user entries. Both servers are fully updated.
>> SSSD and 389DS package versions:
>> sssd-1.9.2-129.el6_5.4.x86_64
>> 389-ds-base-1.2.11.15-31.el6_5.x86_64
>> 
>> Authoconfig was used to enable sssd.
>>  authconfig --enablesssd --enablesssdauth
>> --ldapbasedn=dc=users,dc=company,dc=tld --enableshadow
>> --enablemkhomedir --enablelocauthorize --update
>> PAM an NSS configs were updated as well.
>> I have attached our sssd.conf.
>> 
>> The setup itself works allowing users to authenticate, but we are
>> concerned about the performance.
>> At first we tried with enumeration enabled, but there was a
>> significant responsiveness drop during enumeration. A simple getent
>> -s sss passwd USERNAME took more than 15 seconds. Result paging did
>> not help.
>> 
>> Next we turned enumeration off and deleted the cache for a clean
>> start. We tried simple getent requests with 1000 random usernames
>> taken from a file. We ran the bash script consecutively a few times.
>> The results:
>> - run 1: 0m10.831s
>> - run 2: 0m20.914s
>> - run 3: 0m31.422s
>> and so on. Each run took about 10 seconds more than the previous one.
>> During the test sssd_be was using 100% of one core. During this time
>> 389DS was practically idling. Its load (CPU, I/O) hardly showed any
>> change.
>
>Do you also see bad performance when the cache is not empty? (For
>instance when many users log in in the morning when the day starts..)
>
>> 
>> What could be the reason for this performace issue?
>> How would we best go about tuning this system?
>
>One thing that might help would be fine-tuning the cache expiration, in
>particular entry_cache_nowait_percentage. This midpoint refresh would
>allow the SSSD to return data from cache right away while issuing an
>update in the background.
>
>Some users have also symlinked the cache to /dev/shm, but putting the
>cache to ramdisk obviously removes it on reboot.
my line in /etc/fstab. (I had it for testing purpose)

tmpfs   /var/lib/sss/db/ tmpfs size=300M,mode=0700,noauto,rootcontext=system_u:object_r:sssd_var_lib_t:s0 0 0

LS


More information about the sssd-users mailing list