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 18.104.22.168 we used to
>>>> 'reload' out backend database occasionally as non-indexed reads
>>>> 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
>>>> Is such occasional re-building of the backend database recommended in
>>>> 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?
> 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
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
Hm, looking at it again, perhaps so. I've now patched this in git master to
avoid the issue.
-- Howard Chu
CTO, Symas Corp.