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' )
