Is there any way to see what fields are index'ed? Thanks, _____________________________________________________ John Moyer Director, IT Operations Digital Reasoning Systems, Inc. [email protected] Office: 703.678.2311 Mobile: 240.460.0023 Fax: 703.678.2312 www.digitalreasoning.com
On Aug 27, 2013, at 10:36 AM, John Moyer <[email protected]> wrote: > 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 <[email protected]> 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 >
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Freeipa-users mailing list [email protected] https://www.redhat.com/mailman/listinfo/freeipa-users
