[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