[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: OpenLDAP-2.0.11 and DB 3.2.9 caching problems



You should be able to tune BDB3 through the environment
configuration file.  This allows setting of larger cache
sizes and ncache (without having to modify openldap code).

OPENLDAP_REL_ENG_2 code contains a number of fixes to
the LDBM/BDB3 code.  HEAD contains additional features,
including per database environments and a "sync daemon".

Kurt

At 05:50 AM 7/18/2001, Lawrence, Al (A.D.) wrote:
>After applying the fixes to allow 2.0.11 to use DB 3.2.9 I've noticed that when running SLAPADD, only one file (id2entry.dbb - the first opened?) seems to be cached while the others seem to be written out immediately (i.e. not cached). I really need to have cache for all the .dbb files (32 indexes) since I'm processing a 677Meg LDIF that results in about 2.6Gig(1.9Gig for id2entry alone!) of database files. Can anyone find the bug or explain what is happening? I've already contacted Sleepycat but they claimed not to know of any problem like this with environment cache and pointed me here. As I type this I wonder if "env" is being corrupted some how...
>
>The other problem I have is with setting "dbcachesize". I really need to have more than 2Gig of cache (probably more) to avoid the LDIF load from taking forever. The code (ldbm.c) only really allows you to set cache to 1Gig (even though it accepts numbers up to 2 Gig[ 4 if thats an unsigned int]). Sleepycat's documentation says "int DBENV->set_cachesize(DB_ENV *dbenv, u_int32_t gbytes, u_int32_t bytes, int ncache);". Looking at ldbm.c's call to DB's setcachesize method "env->set_cachesize( env, 0, dbcachesize, 0 ); " it only passes dbcachesize in the "bytes of cache". From the documentation that appears to be the number of bytes less that a Gig. The "Gbytes of cache" parm is set to 0. Shouldn't the dbcachesize be divided into the number of Gig's(gbytes) and the remainder(bytes) in the call? Also my architecture  would like to have the cache allocated in chunks instead of one big malloc. DB has a parameter for that "ncache" (they indicate this is necessary for SUN's) which i!
s!
> set to 0 in ldbm.c.  Shouldn't there be a config option like "dbcachechunks" to set that? I've been toying with a fix for this but wondered if anyone else has dealt with this before (why reinvent the wheel?).