[Date Prev][Date Next]
RE: back-bdb2 in progress
At 12:34 AM 3/15/00 -0800, Howard Chu wrote:
>My quick fix for slow add times, which Kurt wasn't too keen on:
For numerous reasons... first being that it doesn't solve the
problem and two there are reasonable workarounds to build robust
configurations (using slaves). If you want a single server solution,
then you should not defer the sync the disk.
>I delay all write-syncs, maintaining a "dirty" flag for each cache.
>Then on any read operation, cache is flushed if "dirty" is true.
Not needed. The underlying databases maintains "dirty" bits.
We just need to call ldbm_cache_flush_all().
>bulk loading of data to occur pretty quickly, and all you need to do is
>issue a search command to perform a sync as desired.
We should require modification of clients to do server-side
syncing. syncing should be based solely on update operations.
>(Kurt said the right
>solution is to get back-bdb2 up to snuff. Yes, true, but my approach
>provides immediate relief for a pretty common complaint.)
One possible alternative is to disable the per ldbm write sync
and do a ldbm_cache_flush_all() after each ldap update operation.
Another alternative is to use a timer approach.
> -- Howard Chu
> Chief Architect, Symas Corp. Director, Highland Sun
> http://www.symas.com http://highlandsun.com/hyc
>> -----Original Message-----
>> From: owner-openldap-devel@OpenLDAP.org
>> [mailto:owner-openldap-devel@OpenLDAP.org]On Behalf Of Andrew Davison
>> Sent: Tuesday, March 14, 2000 7:48 PM
>> To: openldap-devel
>> Subject: back-bdb2 in progress
>> Is anything happening with BACK-BDB2? I haven't seen any mention
>> of it for a
>> while. The last thing I saw was something about abandoning it and
>> restarting, which doesn't bode well as it's supposed to be the panacea to
>> slow add times without setting 'dbcacheNoWsync'.