George Daswani wrote: >> 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))" > 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. > > > -- > Fedora-directory-users mailing list > Fedora-directory-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3178 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.fedoraproject.org/pipermail/389-users/attachments/20060802/555e62a2/attachment.bin
