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

_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Reply via email to