> George Daswani wrote: >>> George Daswani wrote: >>> >> >> I did the following per your statement above.. >> >> ldapsearch -D "cn=Directory Manager" -x -W >> "(&(employeeNumber=*)(objectClass=icasOrgPerson))" -b >> "ou=Users,ou=Internal,o=TEST,o=US" >> >> ou=Users,ou=Internal,o=TEST,o=US only holds icasOrgPerson type users >> (4778 >> in total) and all of those records have an employeeNumber. >> >> the rest of the users live in >> >> ou=Users,ou=External,o=TEST,o=US (around 345K+, none of which are >> icasOrgPerson's) >> >> Running the search string above, the search is still unindexed (returns >> nentries=4778 notes=U) and is slow. >> >> Searches like the following are very fast (indexed per the access log) >> >> "(&(employeeNumber=2549)(objectClass=icasOrgPerson))" >> > Right. Because there is only one matching entry in the index for > employeeNumber. >> it's weird that searches are so slow (not using indeces) considering the >> number of actual icasOrgPerson (objectClass) is quite low (5K out out of >> the 450K users), and that there's a presence index on the employeeNumber >> attribute (which only exists in icasOrgPerson objects) along with a >> searchbase. >> > Well, in this case, it has to iterate through the employeeNumber index > and return each one of several thousand. >> The index files aren't corrupt and I even recreated the database using >> ldif2db just to make sure everything was fine with the same result. >> >> > If you really need to perform searches like this that return a very > large result set, I suggest you look into the Fedora DS Virtual List > View feature which allows you to page through a sorted result set, or > increase your nsslapd-idlistscanlimit. > > See > http://www.redhat.com/docs/manuals/dir-server/ag/7.1/index1.html#1095569 > for more details. >> >> Richard, thanks for the tip, the default value of the nsslapd-idlistscanlimit is 4K, and the result set that i'm looking at is around 4778 entries so that it's past the tipping point and is not using the indeces. I originally found it odd because I was expecting index handling to be somewhat like how openldap 2.3.25 uses it (I loaded the same data set, same indeces, same hardware, os) and openldap didn't break a sweat returning the result set (instantaneous and fast, the difference between 15 seconds vs 154+ seconds on FDS). I'll bump up the nsslapd-idlistscanlimit to 5K or so and will try again (i'll do some further research in regards to a vlvindex). It's normal for the ldap server in our use-case to generate such large user entries. Non-LDAP aware systems import such data nightly - such is life I guess. G
