[email protected] wrote: > 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)
Have you looked at the slapd debug output with FILTER output enabled? > > 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' ) -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
