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%).
*[Details]*
- We are running on a VM with RedHat with 4 process with 24 Go RAM. - The version of the OpenLDAP is 2.4.16. - We have 2 500 000 accounts.
*[Attachment]*
- *201111223_os.txt* -> informations about OS and Hardware. - *openldap_version.txt* -> informations about the version of OpenLDAP. - *20111220_stats.txt* -> informations about index and perf. - *olcDatabase={1}hdb.ldif.txt * -> informations about hdb config.
Do not hesitate if you need some more informations.
Thank you for your help (:
Mathieu
Sorry for the disturbing, I will be on hollidays the next week.
If you have any suggestion, thanks to contact Antoine (my coworker).
Regards,
Mathieu
2011/12/23 External Mathieu DEDECKER (CAMPUS) <external.z02mdebe@oxylane.com
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%).
*[Details]*
- We are running on a VM with RedHat with 4 process with 24 Go RAM.
- The version of the OpenLDAP is 2.4.16.
- We have 2 500 000 accounts.
*[Attachment]*
- *201111223_os.txt* -> informations about OS and
Hardware.
- *openldap_version.txt* -> informations about the version
of OpenLDAP.
- *20111220_stats.txt* -> informations about index and
perf.
- *olcDatabase={1}hdb.ldif.txt * -> informations about hdb config.
Do not hesitate if you need some more informations.
Thank you for your help (:
Mathieu
--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
openldap-technical@openldap.org