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.