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

Re: Memory leak?



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).

>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).

> 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).

Kurt