Odd performance problem, server not using indeces

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 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





[Index of Archives]     [Fedora User Discussion]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora News]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora QA]     [Fedora Triage]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Yosemite Photos]     [Linux Apps]     [Maemo Users]     [Gnome Users]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Maemo Users]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Fedora ARM]

  Powered by Linux