Quanah Gibson-Mount wrote: > --On Sunday, August 30, 2020 4:48 PM +0000 chrichardso27(a)gmail.com wrote: > > > Search with filter "(abc=cn=foo,dc=bar)" returns close to > > the amount of > > entries in the database (2M) as candidates, and is somewhat equally slow > > than "(&(objectClass=someClass)(abc=cn=foo,dc=bar))", around 15 seconds. > > > > However, search with filter "(abc=cn=bar,dc=baz)" returns a subset of the > > index of abc and performs reasonably fast (1-2 seconds). > > > > This is rather weird and I have no clue on what might be causing the > > issue. > Can you provide: > > a) The actual queries (filter, base, etc)
Using ldapsearch ldapsearch \ -L \ -x \ -H ldap://localhost:1389 \ -D "cn=admin,cn=directory,dc=example,dc=org" \ -w secret \ -b cn=directory,dc=example,dc=org \ "(&(objectClass=someClass)(abc=cn=foo,dc=bar,cn=server,ou=system,cn=directory,dc=example,dc=org))" Note that in this specific case, Rebuilding a database from scratch with a different data does not reveal to problem. I have a specific LDIF exported using slapcat (which I sadly cannot share) with which I can reproduce the problem each time. One thing that I have not mentioned previously is that we have a two node system where to other node is a failover node but is continuously kept up to date using syncrepl. I'm just doing random guesses here as I'm running out of ideas: - Could this be a syncrepl issue - Could there be a bug how OpenLDAP decides the candidates when processing the respective index Anyways, again, any ideas would be greatly appreciated! Few more things I have tried during these few days: - Restore backup prior the incident (works of course but not a solution at this point as the root cause remains to be unknown) - With bdb, use linearindex (didn't fix the issue) - With bdb, set dbpagesize for the index files (didn't succeed as the slapadd runs out of memory for some reason...) > > b) The schema definition of the attribute in question. attributetype ( 1.3.6.1.4.1.14761.1.26 NAME 'abc' DESC 'A description' EQUALITY distinguishedNameMatch SYNTAX '1.3.6.1.4.1.1466.115.121.1.12' ) > > Thanks, > Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com>
