Re: Memory leak?

[Yuri Rabover <yurir@3Cube.com>]

"Kurt D. Zeilenga" wrote:
> 
> At 11:12 AM 9/14/99 -0700, Yuri Rabover wrote:
> >
> >
> >"Kurt D. Zeilenga" wrote:
> >>
> >> At 09:57 AM 9/14/99 -0700, Yuri Rabover wrote:
> >> The slapd will grow until its cache is full.
> >I have 2 indices (abcommonname - all, abuid - eq) and the cache
> >size was set to 1Mb. slapd started at 10Mb and I waited it to grow
> >up to 32Mb. According to the docs, it should have up to 1Mb per
> >index file and 32Mb is much more than that. Anything else I am
> >missing in this setup?
> 
> cachesize vs dbcachesize.
> 
> cachesize, in general, has a larger impact on overall memory
> usage than dbcachesize (which only effects indices).
> 
> A cachesize of n allows n entries to be cached regradless
> of in-memory size of each entry.  You need to scale your
> cachesize appropriately to your entry.  I usually scale
> cachesize based upon the average on-disk size of entries
> (sizeof id2entry / number of entries).

I had cachesize equal to 1000. An entry is roughly 1Kb, so 1000
entries will translate to an extra meg which is not what I've seen.
> 
> >Also, until I kill the server (and it updates the files) ldbmcat
> >returns nothing.
> 
> Good.  The server generally has id2entry opened for writing.
> It's not safe to allow reads during writes concurrently.
> 
> >It makes me believe that the actual database on
> >disk is inconsistent until I kill the server.
> >Enabling cache writes is not an option (too slow).
> 
> If you disable write sync, the in-memory representation is
> not sync'ed to disk until shutdown.  If slapd crashes, it
> may loss and/or corrupt the on-disk representation.  I only
> recommend disabling write syncs when the server does not
> master any data item.  That is, all information is a replica
> from some other source (LDAP or other).

We are implementing a general-purpose address book using LDAP
and this model assumes occasional writes from multiple clients.
Depending on the mode (a simple update vs. import), writes
can take visible amount of time. With cache write enabled an average
entry update takes 2 seconds which is totally unacceptable.
I could live with the model, which would allow me to do massive writes
with no sync with a sync on-demand. Is there any way to add a sync-on-
demand call (by accessing some magic attribute)? If I don't find
any other good methods, I may consider doing this myself but this is
a last resort and I don't have much time.
> 
> > Are there any other methods?
> 
> Safe writes using ldbm technlogy is slow.  We have a new
> database backend (back-bdb2) in the works.  It is
> still highly experimental (-devel only).

As usual, no delivery estimates? :-).

Thanks,
		Yuri