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(a)zimbra.com>wrote:
> --On Tuesday, May 31, 2011 4:49 PM -0500 Mark <mah042(a)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
>
