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.