[Date Prev][Date Next]
Root cause: Strange OpenLdap performace issue
- To: firstname.lastname@example.org
- Subject: Root cause: Strange OpenLdap performace issue
- From: "Michele Mase'" <email@example.com>
- Date: Sun, 6 May 2012 14:33:14 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:x-google-sender-delegation:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=2jDXyvMdImcAdztpLAHSRfb57GpucOESB1ROUfu1WIc=; b=VQ7XQK7uaXKkG6SuEqpBV14iUpZBJStbG62ss0GjA3qc9xm5APyVJFb6nu3qlS5OKO lYkmgX11ejkoujFN66TmxArJMSM4ve2ui65kLQWSKqVzF2kXw4SgfoiBQcrk1b3XKvNa zmzrUNmElQL6EELzCbvWpJyjdGmlc+cso075dpBJoENzCj91tW1swXE5Nfn+y/CtLeUg wOHSTNGLUCMVUltzO9ezGz/pQ40j0JU3TdelB7OtAjZZaTmNMkP9Dx6DpuCQCKTRYa+h Xkevn6Lt1Tm01SJVzaZJOvnEpZBu9TBphEEP7NFLsgymgeczhq+FlnlBpJhH+Cy/9RZ0 9FMQ==
I've a tiny ldap service (only 6000 records) vith openldap 2.3.x rhel5.x master/slave;
The first query takes me over 4 seconds (instead of taking less than 0.1.seconds):
time ldapsearch -x -b "c=it" -s sub "(o=*)" -D "cn=Manager,dc=sir" -h www.example.com -w mypasswd
The same query using one level takes only 0.4 seconds
time ldapsearch -x -b "c=it" -s one "(o=*)" -D "cn=Manager,dc=sir" -h www.example.com -w mypasswd
I've tested the following:
New brand system with openldap 2.4.x rhel6.x mirror mode: both queries take me less than 0.2 seconds
New brand system with the same releases, 2.3.x rhel5.x: both queries take me less than 0.2 seconds
The problem should be in the prod. system:
I've tried almost all: reindexing operations, better indexing options, more cache, better threads tuning, more cpu and ram to the servers ... nothing to do: the first quey takes more than 4 seconds.
The last operation was a "disaster recovery" of the prod. ldap:
1 stop ldap on both systems
2 slapcat to save the last good ldif
3 remove of all databases (rm -fr /var/lib/ldap/*) on both systems
4 recreate dirs, DB_CONFIG and restore ldif; restore permissions
5 start ldap service on both servers
And magically, the issue has gone!
Now first query, yes the "bad" query with the subtree options, works like a charm, giving me the results in less than 0.1 seconds ....
Which could be the root cause? DB defragmentation? I was unable to find the root cause. PLS, help me to find some suggestions.