Howard Chu wrote:
chrichardso27(a)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?
Debug log using mdb (which experiences the same poor usage of index)
begin get_filter AND begin get_filter_list begin get_filter EQUALITY end get_filter 0 begin get_filter EQUALITY end get_filter 0 end get_filter_list end get_filter 0 => mdb_filter_candidates OR => mdb_list_candidates 0xa1 => mdb_filter_candidates EQUALITY <= mdb_filter_candidates: id=0 first=0 last=0 => mdb_filter_candidates AND => mdb_list_candidates 0xa0 => mdb_filter_candidates EQUALITY <= mdb_filter_candidates: id=-1 first=2 last=2051388 => mdb_filter_candidates EQUALITY <= mdb_filter_candidates: id=-1 first=39 last=2051956 <= mdb_list_candidates: id=-1 first=39 last=2051388 <= mdb_filter_candidates: id=-1 first=39 last=2051388 <= mdb_list_candidates: id=-1 first=39 last=2051388 <= mdb_filter_candidates: id=-1 first=39 last=2051388 => test_filter AND => test_filter_and => test_filter EQUALITY <= test_filter 6 => test_filter EQUALITY <= test_filter 6 <= test_filter_and 6 <= test_filter 6 => test_filter AND => test_filter_and => test_filter EQUALITY <= test_filter 5 <= test_filter_and 5 <= test_filter 5 => test_filter AND => test_filter_and => test_filter EQUALITY
And this repeats on and on.
Furthermore, with -d 1 and -d 32 I get:
=> mdb_equality_candidates (objectClass) => key_read <= mdb_index_read 2051387 candidates <= mdb_equality_candidates: id=-1, first=2, last=2051388 <= mdb_filter_candidates: id=-1 first=2 last=2051388 => mdb_filter_candidates EQUALITY => mdb_equality_candidates (abc) => key_read <= mdb_index_read 2051918 candidates
Again, almost all entries in the database are considered as candidates for the problematic attribute. However, this is not the case as there are only few entries having that attribute specified.
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' )