...

...

Norbert openldap@freakix.de schrieb am 24.08.2022 um 11:27 in Nachricht

7c7bb2e6-d037-7069-9e32-0851e685c6c0@freakix.de:

Hi,

with OpenLDAP 2.4.47 (running on Debian 10) but also with 2.5.13 from ltb-project.org (running on same Debian 10) I can observe the following:

given following rough idea of a tree

o=base |- bn=subtree1 | - handful of entries |- bn=subtree2 | - millions of entries |- bn=subtree3 | |- bn=sub-subtree1 | |- bn=sub-subtree2 | |- some entries |- bn=subtree4

ou is an indexed attribute with pres,eq,sub. When now searching with the

And is bn indexed, too?

filter bn=<value> then there is a significant difference when searching for either subtree1 and subtree2 as values in the range of seconds. This means on command line ldapsearch with subtree1 it is around 0.007 seconds and with subtree2 4.5 seconds before the fully finishes.

When I change the search filter to "(&(objectClass=bnClass)(bn=<value>))" then this has no real impact to the time needed searching for subtree1 but improves searching subtree2, still it more than 2 times slower than searching for subtree1. Only entries with objectClass=bnClass have the bn attribute but no other entries.

Changing the scope to one, yields similar times when searching for subtree1 and subtree2 but the search itself also to cover searching for sub-subtree1 or sub-subtree2 with the same search task as it is not known where such sub-subtree could be found.

The only pattern I've found so far is that if there are millions of entries in a subtree then finishing the search takes much longer.

The LDAP is using MDB, and has been completely rebuilt (means slapcat/slapadd) several times with always showing the same results. There was no difference between 2.4 and 2.5.13.

Is there something which can be improved by changing the configuration?

Thanks, Norbert

--On Wednesday, August 24, 2022 12:27 PM +0200 Norbert openldap@freakix.de wrote:

Hi,

with OpenLDAP 2.4.47 (running on Debian 10) but also with 2.5.13 from ltb-project.org (running on same Debian 10) I can observe the following:

given following rough idea of a tree

o=base |- bn=subtree1 | - handful of entries |- bn=subtree2 | - millions of entries |- bn=subtree3 | |- bn=sub-subtree1 | |- bn=sub-subtree2 | |- some entries |- bn=subtree4

ou is an indexed attribute with pres,eq,sub.

Two comments:

a) pres indices are almost always worthless. They are only needed if you're going to be presence checking on an attribute that exists in < 50% of the entries. Do you really do presence checks on ou? See also https://www.openldap.org/doc/admin26/tuning.html#Presence%20indexing

Is there something which can be improved by changing the configuration?

You probably want to increase the IDL range if you truely have millions of entries. See also:

https://www.openldap.org/doc/admin26/tuning.html#Indexes

and

https://www.openldap.org/software/man.cgi?query=slapd-mdb&apropos=0&sektion=0&manpath=OpenLDAP+2.6-Release&arch=default&format=html

Specifically the section on "idlexp".

In my current production environment, I have:

dn: olcBackend={0}mdb,cn=config objectClass: olcBackendConfig objectClass: olcMdbBkConfig olcBackend: {0}mdb olcBkMdbIdlExp: 18

Note that olcBkMdbIdlExp is type "backend" and not "database", and applies to *all* mdb databases in the configuration. You will have to re-index the database after setting this, I'd suggest doing that offline with slapindex -q.

Regards, Quanah