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.

Ondrej Kuznik wrote:

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.

Hm, looking at it again, perhaps so. I've now patched this in git master to avoid the issue.