chrichardso27@gmail.com 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' )