George Daswani wrote:
Right. Because there is only one matching entry in the index for employeeNumber.George Daswani wrote:Hello, I have around 350K users in my test directory, and I'm running into an odd problem with the directory not using indeces for ldapsearches. For example, using the following search string (&(objectClass=icasOrgPerson)(employeeNumber=*)) Looking at the console, there's a system index on objectClass (which is set to equality), there's also an index on employeeNumber (both equality, and presence). There are around 5K icasOrgPersons (which can hold the employeeNumber attribute), the rest can't.How many entries match (objectClass=organizationalPerson)? If this number is large, then I think what's happening is that the database first looks up how many match this, and says there are too many. Try using icasOrgPerson or reverse the order of the filters.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))"
Well, in this case, it has to iterate through the employeeNumber index and return each one of several thousand.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.
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.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.
See http://www.redhat.com/docs/manuals/dir-server/ag/7.1/index1.html#1095569 for more details.
-- Fedora-directory-users mailing list Fedora-directory-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-users
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
-- Fedora-directory-users mailing list Fedora-directory-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-users
