Re: LMDB use of sparse or non-sparse data file

[Geoff Swan <gswan3@bigpond.net.au>]

On 26/03/2015 8:13 AM, Geoff Swan wrote:
>
> On 26/03/2015 6:23 AM, Quanah Gibson-Mount wrote:
>> --On Wednesday, March 25, 2015 8:41 AM +1100 Geoff Swan
>> <gswan3@bigpond.net.au> wrote:
>>
>>>> Well, to be clear: While the DB is sparse, mdb_copy does drop the
>>>> unused map space when using mdb_copy by default.
>>> That is what I have seen.
>>> The filesystem reports 2TB file size for the first server, and 590GB
>>> file size for the mdb copy, with default options.
>> Use du -c to get actual used space instead of the maxsize value.
>>
>>>> I think this is the behavior they're referring to.  However, in my
>>>> experience, after starting up slapd with an mdb_copy'd db, where
>>>> sparse files are in use, the size will be set to whatever slapd's
>>>> configured to use after slapd is started.
>>> This is not what is being seen.
>>> The file size remains at 590GB on the server using the copy, and 2TB on
>>> the original server.
>> Then there's something odd happening on your server where you placed
>> the copy.  What OpenLDAP version are you using?
> It is 2.4.39.
> I might try a slapcat/slapadd to rebuild the db file and see if that
> corrects the problem.

Further testing may give some clues. The search is on modifyTimestamp,
in particular branches, to find objects with a modifyTimestamp>=value.
If value is fairly close to the current datetime, the search returns
quickly. However if value is a few days ago then the search appears to
take many hours, even though there are no objects that match the filter
(ie the result set size has no effect). Not sure why this should be the
case, given that modifyTimestamp is indexed, there is plenty of memory
and 30-50% is free during the search operation.

>
>> --Quanah
>>
>>
>> -- 
>>
>> Quanah Gibson-Mount
>> Platform Architect
>> Zimbra, Inc.
>> --------------------
>> Zimbra ::  the leader in open source messaging and collaboration
>>
>