[Freeipa-users] IPA Load Problems?

[Rob Crittenden]

John Moyer wrote:
> Ok, so we tried to implement this again, and as soon as we put on a
> server that authenticates heavily the IPA came to it's knees again.
> This time I was able to watch it closely and try to troubleshoot a lot
> more, and also know exactly what server caused it (Mercurial with help
> of bamboo).   This runs fine on a normal old openldap servers.   The
> user is logging in very quickly and each time it logs in I can see in
> the logs that the krbLastsuccessfullogin parameter (or whatever it is
> called) is updated over and over and over in the changelog
> (/var/lib/dirsrv/slapd-$instanceid/db) those logs are filling VERY
> quickly and then disappear fairly quickly as well.
>
> Issue 1: This is causing severe disk latency which obviously slows
> everything down wait times were around 25%+
> Issue 2: These changes need to be replicated to my slave server thus
> adding to the mess
>
>
> My question is, why does the IPA server fail to keep up with the load
> when the openLDAP server didn't have an issue.   Indexes?
>
>
> I'm running the following:
>
> CentOS release 6.4 (Final)
> 389-ds-base-1.2.11.15-20.el6_4.x86_64
> 389-ds-base-libs-1.2.11.15-20.el6_4.x86_64
> ipa-python-3.0.0-26.el6_4.4.x86_64
> ipa-admintools-3.0.0-26.el6_4.4.x86_64
> ipa-pki-common-theme-9.0.3-7.el6.noarch
> python-iniparse-0.3.1-2.1.el6.noarch
> ipa-server-3.0.0-26.el6_4.4.x86_64
> ipa-pki-ca-theme-9.0.3-7.el6.noarch
> ipa-server-selinux-3.0.0-26.el6_4.4.x86_64
> libipa_hbac-1.9.2-82.7.el6_4.x86_64
> ipa-client-3.0.0-26.el6_4.4.x86_64
> libipa_hbac-python-1.9.2-82.7.el6_4.x86_64
>
>
> So I've implemented this server anyway (against my better judgement with
> these issues and just made the user that logs into mercurial a local
> user instead of IPA).
>
> Also note before I did that for fun I implemented a RAM disk to put the
> change logs on, and that dropped the wait time to 0 (except bursts where
> it would raise to 30 to write the access log) but the CPU drove to 100%
> trying to keep up with the load.  I have also killed the replication as
> well.
>
> Any help would be appreciated.
>

krblastsuccessfulauth should be excluded from replication, though I 
guess that doesn't prevent it from ending up in the changelog.

You can confirm that they are excluded by searching the agreements:

$ ldapsearch -LLL -x -b 'cn=mapping tree,cn=config' -D 'cn=directory 
manager' -W nsDS5ReplicatedAttributeList nsDS5ReplicatedAttributeListTotal

They should look like:

nsDS5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE memberof 
idnssoaserial entryusn krblastsuccessfulauth krblastfailedauth 
krbloginfailedcount

nsDS5ReplicatedAttributeListTotal: (objectclass=*) $ EXCLUDE entryusn 
krblastsuccessfulauth krblastfailedauth krbloginfailedcount

rob