https://bugs.openldap.org/show_bug.cgi?id=9261
Bug ID: 9261 Summary: Slow subtree search when starting in large containers Product: OpenLDAP Version: 2.4.44 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs@openldap.org Reporter: matthew.slowe@jisc.ac.uk Target Milestone: ---
Using "hdb" database type in slapd 2.4.44 on RedHat Enterprise Linux 7.8
When doing an indexed subtree search from a base which has a large number of objects the search result take considerably longer to find then starting "higher" in the tree.
For example:
dc=example,dc=org - 10 objects `- ou=test - 300,000 objects
Tests:
1. Search for (uid=username) basedn:dc=example,dc=org type:subtree 2. Search for (uid=username) basedn:ou=test,dc=example,dc=org type:subtree 3. Search for (uid=username) basedn:ou=test,dc=example,dc=org type:one
Expected results:
All three searches should be roughly the same given that "uid" has an equality index.
Actual results:
1. 0.1s 2. 5.5s 3. 0.1s
A debug trace excerpt of test (2) shows:
May 11 14:55:16 76ffcc7a2f29 slapd[1462]: conn=1000 op=1 SRCH base="ou=test,dc=example,dc=org" scope=2 deref=0 filter="(uid=username)" May 11 14:55:21 76ffcc7a2f29 slapd[1462]: 5eb96759 => bdb_filter_candidates
https://bugs.openldap.org/show_bug.cgi?id=9261
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED
--- Comment #1 from Quanah Gibson-Mount quanah@openldap.org --- Hello,
a) OpenLDAP 2.4.44 is 3 years old. b) back-hdb is deprecated c) back-hdb requires significant tuning to be performant of both the BDB caches and the entry/idl/dn cache
d) what you're describing is generally a known issue with back-hdb until the caches (if properly configured) are primed.
Generally questions such as this should be sent to the openldap-technical list rather than filed in the ITS system.
https://bugs.openldap.org/show_bug.cgi?id=9261
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED
https://bugs.openldap.org/show_bug.cgi?id=9261
--- Comment #2 from matthew.slowe@jisc.ac.uk ---
a) OpenLDAP 2.4.44 is 3 years old. b) back-hdb is deprecated
Do you know, therefore, if this behaviour is not present in more recent version? It's "current" in the RHEL/CentOS 7 platform and, probably, in widespread use.
c) back-hdb requires significant tuning to be performant of both the BDB caches and the entry/idl/dn cache
I don't claim to know a huge amount about the internals of openldap but the discrepancy between the two "sub" searches seemed very bug like to me particularly where it doesn't seem to do any debug log for that length of time.
d) what you're describing is generally a known issue with back-hdb until the caches (if properly configured) are primed.
I do not believe this to be a caching problem, this instance has been "up" and busy for some time and the behaviour is repeated when running the same queries again.
Generally questions such as this should be sent to the openldap-technical list rather than filed in the ITS system.
My apologies. I had searched for a relevant post or issue and, not finding one, this seemed like the best place to make a record of it.
https://bugs.openldap.org/show_bug.cgi?id=9261
--- Comment #3 from Quanah Gibson-Mount quanah@openldap.org --- (In reply to matthew.slowe from comment #2)
a) OpenLDAP 2.4.44 is 3 years old. b) back-hdb is deprecated
Do you know, therefore, if this behaviour is not present in more recent version? It's "current" in the RHEL/CentOS 7 platform and, probably, in widespread use.
It is advised by the project to use current builds, particularly on RedHat. As I noted, back-hdb is deprecated and will be removed for OpenLDAP 2.5. For OpenLDAP 2.4, back-mdb is the recommended backend. No issues with back-hdb are likely to be investigated.
Current builds of OpenLDAP that function as a drop in replacement on RH7 are freely available from https://repo.symas.com/sofl/rhel7/
Alternatively, the LTB project provides current openldap builds as well (https://ltb-project.org/documentation/openldap-rpm#yum_repository)
My general advice would be to (a) install a current version of OpenLDAP and (b) migrate off of back-hdb to back-mdb.
https://bugs.openldap.org/show_bug.cgi?id=9261
--- Comment #4 from matthew.slowe@jisc.ac.uk --- Thank-you for your pointers. Hopefully the bug report will help anyone else who hits this behaviour.
-
openldap-its＠openldap.org