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?
Thank you, Mark
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.
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
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.
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.
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 slapdThen 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.
--On Tuesday, May 31, 2011 4:49 PM -0500 Mark mah042@gmail.com 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?
No. You are having this problem by running ancient releases of OpenLDAP and BDB. BTW, BDB 5.x (5.1 and 5.0) are also fully supported by OpenLDAP 2.4.23 and later.
--Quanah
--
Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
openldap-technical@openldap.org
-
Howard Chu -
Mark -
Ondrej Kuznik -
Quanah Gibson-Mount