Hi Quanah and thank you again for your quick reply, I did not deleted the *.bdb files, but I moved them in a backup folder.
My /db folder was empty, but the slapindex command failed because both "dn2id.bdb" and "id2entry.bdb" files was not present. I needed to add them in the /db folder in order to run the slapindex command. Then, all index have been re-generated. After the reindexation, the "cardnumber.bdb" file had the same size than before. Could you confirm me that it's the best process to reindex an OpenLDAP? Thank you, Mathieu 2012/1/5 Quanah Gibson-Mount <[email protected]> > Hi Mathieu, > > It sounds like you didn't delete the cardnumber.bdb file before > reindexing? That is what I'd have done. > > Also, you previously had some questions about OpenLDAP tuning. You may > wish to read over <http://wiki.zimbra.com/wiki/** > OpenLDAP_Performance_Tuning<http://wiki.zimbra.com/wiki/OpenLDAP_Performance_Tuning>>. > Some of the bits in there have Zimbra specific names, but they all apply > directly to OpenLDAP and BDB in general. > > --Quanah > > > --On Wednesday, January 04, 2012 2:46 PM +0100 "External Mathieu DEDECKER > (CAMPUS)" <[email protected]**> wrote: > > I will read the man page in order to have more informations about the >> command. >> >> I tried to reindex all the index of the database with the slapindex >> command, but I allways the same behaviour: >> >> Request1: cardnumber=2098001010034 (less than 1sec) >> Request2: cardnumber=2090389917486 (nearly 20 sec). >> >> Other .bdb files size have been updated, but my "cardnumber.bdb" has >> still the same size. >> >> Regards, >> >> Mathieu >> >> >> 2012/1/4 Quanah Gibson-Mount <[email protected]> >> >> Hi Mathieu, >> >> If you read the slapindex man page, it is possibly to just recreate a >> specific index file (for situations like this), rather than generating >> all of them. >> >> --Quanah >> >> >> --On Wednesday, January 04, 2012 10:39 AM +0100 "External Mathieu >> DEDECKER (CAMPUS)" <[email protected]**> wrote: >> >> >> >> Hello Quanah, >> >> First I would like to thank you for your answer. >> >> Indeed, I also think that the "cardnumber" index is somehow corrupted. >> His size is to small in comparison to other indexes >> >> We suppressed all existing index and Used slapindex to re-create them all. >> >> It's undergoing. >> >> I will keep you informed about the solution. >> >> Best Regards, >> >> Mathieu >> >> >> 2012/1/3 Quanah Gibson-Mount <[email protected]> >> >> >> >> >> >> --On Friday, December 23, 2011 11:27 AM +0100 "External Mathieu DEDECKER >> (CAMPUS)" <[email protected]**> wrote: >> >> >> Hi @All, >> >> We meet a performance problem with our OpenLDAP. >> >> We think that we face a problem with the index of the database, and we >> think that the problem can be resolve by tunning the config (but not >> sure). >> >> We would like to be sure that our configuration is correct, in order to >> confirm if we are on a wrong track or not. >> >> [Description] >> >> We have an attribute (cardNumber) which is indexed. >> >> When we request the indexed attribute (cardNumber) with an LDAP Client >> (Ldapbrowser), we have either fast or very long response time. >> >> For the long response time, the CPU of the server hits 100%. >> >> For example: >> >> Request1: cardnumber=2098001010034 (less than 1sec) >> Request2: cardnumber=2090389917486 (nearly 20 sec). >> >> By checking the hit ratio of the attribute, we can see that cache is >> correctly used (97%). >> >> >> It sounds like you added an index to cardnumber after there was already >> data for cardnumber in your database, and didn't run slapindex for that >> attribute. Alternatively, your cardnumber.bdb file is corrupted. >> >> --Quanah >> >> >> -- >> >> Quanah Gibson-Mount >> Sr. Member of Technical Staff >> Zimbra, Inc >> A Division of VMware, Inc. >> -------------------- >> Zimbra :: the leader in open source messaging and collaboration >> >> >> >> >> >> >> >> >> >> -- >> >> Quanah Gibson-Mount >> Sr. Member of Technical Staff >> Zimbra, Inc >> A Division of VMware, Inc. >> -------------------- >> Zimbra :: the leader in open source messaging and collaboration >> >> >> > > > -- > > Quanah Gibson-Mount > Sr. Member of Technical Staff > Zimbra, Inc > A Division of VMware, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration >
