On 06/01/2011 08:30 AM, Howard Chu wrote:
Ondrej Kuznik wrote:
> On 06/01/2011 12:12 AM, Howard Chu wrote:
>> Mark wrote:
>>> Back in the days of OpenLDAP 2.1 with Berkeley DB 4.1.25.3 we used to have
to
>>> 'reload' out backend database occasionally as non-indexed reads would
get
>>> slower and slower over time. The 'reload' entailed:
>>>
>>> * stop slapd
>>> * slapcat the contents to an .ldif file
>>> * remove the database files
>>> * slapadd the .ldif file to create a new, fresh db instance
>>> * start slapd
>>>
>>>
>>> Then our performance problems went away. Re-indexing didn't do the
trick.
>>>
>>> Is such occasional re-building of the backend database recommended in
OpenLDAP
>>> 2.4.25 with Berkeley DB 4.8.30?
>>
>> Try it and see.
>>
>> Non-indexed reads are always going to be pretty slow, regardless.
>
> Might be that he's hitting this?
>
http://www.openldap.org/lists/openldap-technical/201011/msg00146.html
Clearly not, since that message is all about indexing, and he's talking about
non-indexed reads.
As far as I have understood that message of yours, the "index" is a list
of all the entries in the subtree. That should have nothing to do with
attribute indexing. Might be that I completely misunderstood that issue
but looking at the testbed you attached in
http://www.openldap.org/lists/openldap-technical/201011/msg00148.html I
see no filter passed to ldapsearch so no attribute indexes should apply.
Please do correct me if I'm wrong in any of the above as that implies I
have misunderstood a part of how OpenLDAP works thus need to revisit
relevant documentation and play with it more to prevent it biting me
later on.
--
Ondrej Kuznik
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It
may contain proprietary material, confidential information and/or be subject to legal
privilege. It should not be copied, disclosed to, retained or used by, any other party. If
you are not an intended recipient then please promptly delete this e-mail and any
attachment and all copies and inform the sender. Thank you.