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.