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?

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

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.