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 quanah@zimbra.comwrote:

--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