--On Wednesday, October 12, 2016 10:11 PM +0200 Rébeli-Szabó Tamás
we are on OpenLDAP 2.4.41 + MDB, Oracle Linux 6 (2.6 x86_64).
In our DIT we have around 300 groups, with tens of thousands of members
in each group. When we want to know which groups a certain user belongs
to, it takes OpenLDAP several seconds to perform such a search.
Here is a log excerpt showing that it took 6 seconds for the server to
Oct 10 15:39:38 ldap-srv1 slapd: conn=1062 op=1 SRCH
base="ou=groups,dc=tt,dc=hu" scope=1 deref=0
Oct 10 15:39:44 ldap-srv1 slapd: conn=1062 op=1 SEARCH RESULT
tag=101 err=0 nentries=127 text=
We have eq indices on objectClass and uniqueMember, and the latter is
also listed after sortvals.
The machine running OpenLDAP has 2 virtual cores of Intel Xeon E5 2637 v2
(3.5GHz). During such searches, one of the CPU cores is almost fully
loaded, but the system is not overloaded (the average load is around
0.8). Our whole dataset is under 1 GB, and there are several gigabytes
of free RAM with no swapping.
Our expectation would be for OpenLDAP to give an answer to a group
membership question under 1 second. Is that a realistic expectation, and
if so, how should we tune OpenLDAP or what do you suggest we change?
Version 2.4.41 is more than a year old, so the question is if there is
any significant performance enhancement (an order of magnitude) possible
with this setup described above, or that's about all we can get from
OpenLDAP+MDB (or perhaps any in-memory LDAP)?
Does it always take 6 seconds to return the 127 group entries that match,
or is that only on the first search?
Packaged, certified, and supported LDAP solutions powered by OpenLDAP: