[Freeipa-users] IPA Load Problems?

[John Moyer]

That looks like the output I just got shown below: 


dn: cn=mapping tree,cn=config

dn: cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config

dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config

dn: cn=meToipa2.example.com,cn=replica,cn=dc\3Dexample\
 2Cdc\3Dcom,cn=mapping tree,cn=config
nsDS5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE memberof idnssoaserial
  entryusn krblastsuccessfulauth krblastfailedauth krbloginfailedcount
nsDS5ReplicatedAttributeListTotal: (objectclass=*) $ EXCLUDE entryusn krblasts
 uccessfulauth krblastfailedauth krbloginfailedcount


Thanks, 
_____________________________________________________
John Moyer
Director, IT Operations


On Aug 27, 2013, at 10:14 AM, Rob Crittenden <rcritten at redhat.com> wrote:

> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20130827/3dd52e5f/attachment.sig>