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 over 4.8.30? On Tue, May 31, 2011 at 5:27 PM, Quanah Gibson-Mount <[email protected]>wrote: > --On Tuesday, May 31, 2011 4:49 PM -0500 Mark <[email protected]> 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 >
