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 quanah@zimbra.com
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)" <external.z02mdebe@oxylane.com**> 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 quanah@zimbra.com
--On Friday, December 23, 2011 11:27 AM +0100 "External Mathieu DEDECKER (CAMPUS)" <external.z02mdebe@oxylane.com**> 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
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. 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)" external.z02mdebe@oxylane.com 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 quanah@zimbra.com
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)" external.z02mdebe@oxylane.com 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 quanah@zimbra.com
--On Friday, December 23, 2011 11:27 AM +0100 "External Mathieu DEDECKER (CAMPUS)" external.z02mdebe@oxylane.com 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
openldap-technical@openldap.org
-
External Mathieu DEDECKER (CAMPUS) -
Quanah Gibson-Mount