[Fedora-directory-users] Odd performance problem, server not using indeces

George Daswani funks at socalsrt4.com
Thu Aug 3 00:21:06 UTC 2006


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

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.

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.







More information about the 389-users mailing list