[Date Prev][Date Next] [Chronological] [Thread] [Top]

group membership search performance


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 answer:

Oct 10 15:39:38 ldap-srv1 slapd[14776]: conn=1062 op=1 SRCH base="ou=groups,dc=tt,dc=hu" scope=1 deref=0 filter="(&(uniqueMember=uid=o10011,ou=users,dc=tt,dc=hu)(objectClass=groupOfUniqueNames))" Oct 10 15:39:44 ldap-srv1 slapd[14776]: 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)?