[Date Prev][Date Next]
Re: syncrepl replication taking too long(not sync)
- To: email@example.com
- Subject: Re: syncrepl replication taking too long(not sync)
- From: Rodrigo Costa <firstname.lastname@example.org>
- Date: Tue, 18 Aug 2009 14:13:46 -0700 (PDT)
- Cc: email@example.com
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1250630026; bh=G8G58RSnR2z4J2eEDH6tWCaUBWFnDZP5HJdCAi+PXHo=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=li8rjR5lwSs/EErV3ihBPW0Oav6XvUQdbGC09KHub1KAO6ChhXvRwPpxFIvdK6IJoGA5XnwLZrE2gPqk1l3pthy+kfgUR2TcVy/SxXnay1whf1DPMnuosMd+zfLm1Sho/MjGb2wpDmV+0ecbLox5f03unjFZaCKDcsgrTz1vvZc=
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=Rgxes9JgMkllA/cJHPgEndeiVpnnhX1O/rCpKRinRB91pSC6f7UQPKjjG4O58LVq7edPQmskmA1J0dVeQ2Xl3rxGwtOwOhmKxF/+ToGN5atpQS7pMwY9F/ddQks1lTVXCLVlqXc8gbmlthnK554qScF+6Hc4zxymyT4ZjGYXhCY=;
The issue is that if I do not limit dncache the slapd crashes since
after sometime it cannot allocate more system memory(malloc). Only
dncache in two DBs can consume all memory possible to allocate.
Quanah Gibson-Mount wrote:
> --On Tuesday, August 18, 2009 1:30 PM -0700 Rodrigo Costa
> <firstname.lastname@example.org> wrote:
>> openldap software community,
>> I'm facing some difficulties to have database synchronized with
>> syncrepl. I'm running the latest openldap 2.4.17 version which after
>> these issues I compiled with gdb.
>> I have a DB(divided really in 2 DBs) where each one has around 4 million
>> entrances. Based in memory limitations I have a dncachesize configured
>> with around 3000000, or smaller than the maximum number of entrances in
> Don't use a limited dncachesize. With 2.4.18, you'll be able to set
> it to zero (unlimited), and that will be the default, to match the old
> 2.3 behavior. Limit your memory consumption in other ways if you need
> to (Smaller BDB cache, smaller entry cache, smaller idlcache).
> Limiting the dncachesize is pretty much suicidal in any large db.
> Quanah Gibson-Mount
> Principal Software Engineer
> Zimbra, Inc
> Zimbra :: the leader in open source messaging and collaboration