Is there any way to see what fields are index'ed?  

Thanks, 
_____________________________________________________
John Moyer
Director, IT Operations
Digital Reasoning Systems, Inc.
john.mo...@digitalreasoning.com
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 <john.mo...@digitalreasoning.com> 
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 <rcrit...@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
> 

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

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

Reply via email to