Thank you both for your quick response. I understand non-indexed reads will
always be slower than indexed, but it was a batch process and I didn't want
to incur the overhead of another write-impacting index. I've recently come
back to OpenLDAP and so wasn't sure whether the new version's backend became
'fragmented' (for lack of a better term) like the old ones (<=2.1.25) seemed
to. I hoped they did not, but I wanted to confirm as I haven't been running
2.4.25 w/BDB 4.8.30 long enough or under enough load yet to tell. I'm glad
to hear 'defraging' is not required in newer versions.
I will begin testing BDB 5.x as a replacement to our current BDB 4.8.30
backend. Is anyone aware of any technical reasons why one should use 5.1.25
On Tue, May 31, 2011 at 5:27 PM, Quanah Gibson-Mount <quanah(a)zimbra.com>wrote:
--On Tuesday, May 31, 2011 4:49 PM -0500 Mark
Back in the days of OpenLDAP 2.1 with Berkeley DB 188.8.131.52 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.
Sr. Member of Technical Staff
A Division of VMware, Inc.
Zimbra :: the leader in open source messaging and collaboration