Paul B. Henson wrote:
Okay, here is the start of the search:
Oct 21 17:14:35 ldap-dev-03 slapd[4335]: conn=1001 op=1 do_search Oct 21 17:14:35 ldap-dev-03 slapd[4335]: >>> dnPrettyNormal: <dc=cpp,dc=edu> Oct 21 17:14:35 ldap-dev-03 slapd[4335]: <<< dnPrettyNormal: <dc=cpp,dc=edu>, <dc=cpp,dc=edu> Oct 21 17:14:35 ldap-dev-03 slapd[4335]: SRCH "dc=cpp,dc=edu" 2 0 0 0 0 Oct 21 17:14:35 ldap-dev-03 slapd[4335]: filter: (uid=henson) Oct 21 17:14:35 ldap-dev-03 slapd[4335]: attrs: Oct 21 17:14:35 ldap-dev-03 slapd[4335]: ==> limits_get: conn=1001 op=1 self="[anonymous]" this="dc=cpp,dc=edu" Oct 21 17:14:35 ldap-dev-03 slapd[4335]: <== limits_get: type=DN match=ANONYMOUS Oct 21 17:14:35 ldap-dev-03 slapd[4335]: => mdb_search Oct 21 17:14:35 ldap-dev-03 slapd[4335]: mdb_dn2entry("dc=cpp,dc=edu") Oct 21 17:14:35 ldap-dev-03 slapd[4335]: => mdb_dn2id("dc=cpp,dc=edu") Oct 21 17:14:35 ldap-dev-03 slapd[4335]: <= mdb_dn2id: got id=0x1 Oct 21 17:14:35 ldap-dev-03 slapd[4335]: => mdb_entry_decode: Oct 21 17:14:35 ldap-dev-03 slapd[4335]: <= mdb_entry_decode Oct 21 17:14:35 ldap-dev-03 slapd[4335]: search_candidates: base="dc=cpp,dc=edu" (0x00000001) scope=2 Oct 21 17:14:35 ldap-dev-03 slapd[4335]: => mdb_equality_candidates (objectClass) Oct 21 17:14:35 ldap-dev-03 slapd[4335]: => key_read Oct 21 17:14:35 ldap-dev-03 slapd[4335]: mdb_idl_fetch_key: [d913076f] Oct 21 17:14:35 ldap-dev-03 slapd[4335]: <= mdb_index_read 132354 candidates Oct 21 17:14:35 ldap-dev-03 slapd[4335]: <= mdb_equality_candidates: id=-1, first=3, last=132356 Oct 21 17:14:35 ldap-dev-03 slapd[4335]: mdb_search_candidates: id=-1 first=3 last=132356
It looks like is is looking for an objectClass match and then doing a full scan of my entire directory? These lines are followed by thousands and thousands of entries like:
Then it does a lookup on memberUid, presumably because I am using the dynlist module to maintain memberOf:
dynlist-attrset cppEduPerson memberURL memberOf
and my entry has this attribute:
memberURL: ldap:///dc=cpp,dc=edu??sub?(memberUid=henson)
Then this is probably dynlist searching for objectclass=cppEduPerson.
You should change this configuration to use 2.5 dynlist's memberOf support.
Indexing is not broken.
My configuration between 2.4 and 2.5 is pretty much identical. Any idea why it might be fully traversing the directory looking for object class matches?
On 10/21/2021 4:55 PM, Howard Chu wrote:
Paul B. Henson wrote:
Any thoughts on what might be going on or how I can debug it to track down exactly what is causing it? There was obviously a lot more debug info in the logs that I didn't include, but none of it jumped out to me as "smoking gun".
Try the search again with -d5. Also include the lines showing which attribute it's checking in the index. e.g.:
6171fcb7.1be5a183 0x7f28b65fd640 search_candidates: base="dc=example,dc=com" (0x00000001) scope=2 6171fcb7.1be5b227 0x7f28b65fd640 => mdb_equality_candidates (objectClass) 6171fcb7.1be5cfe4 0x7f28b65fd640 => key_read 6171fcb7.1be5e088 0x7f28b65fd640 mdb_idl_fetch_key: [b49d1940] 6171fcb7.1be5faff 0x7f28b65fd640 <= mdb_index_read: failed (-30798) 6171fcb7.1be60a00 0x7f28b65fd640 <= mdb_equality_candidates: id=0, first=0, last=0 6171fcb7.1be61901 0x7f28b65fd640 => mdb_equality_candidates (sn) 6171fcb7.1be62f1a 0x7f28b65fd640 => key_read 6171fcb7.1be63fbf 0x7f28b65fd640 mdb_idl_fetch_key: [03915b69] 6171fcb7.1be659a9 0x7f28b65fd640 <= mdb_index_read 2 candidates 6171fcb7.1be66a94 0x7f28b65fd640 <= mdb_equality_candidates: id=2, first=8, last=9 6171fcb7.1be68cae 0x7f28b65fd640 mdb_search_candidates: id=2 first=8 last=9