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

Re: Memory leak?




"Kurt D. Zeilenga" wrote:
> 
> At 09:57 AM 9/14/99 -0700, Yuri Rabover wrote:
> 
> >"Kurt D. Zeilenga" wrote:
> >> At 08:54 AM 9/14/99 -0700, Yuri Rabover wrote:
> >> >Before submitting a bug report I want to check with the community
> >> >if this is a known behavior.
> >>
> >> See ITS#249, ITS#250 and the OpenLDAP 1.2.7 announcement made on
> >> list just days ago.
> >
> >Updated, cleaned up, reconfigured and rebuilt from 1.2.7. Ran the
> >test for 30 minutes. Same behavior, the process size is constantly
> >growing and doesn't shrink.
> 
> 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?

> >Any information about index file behavior?
> 
> I suspect the index file in question stopped growing because the
> keys being updated reached ALLID status.  That is, the server
> eventually stops maintaining the list of entry ids which have
> a certain characteristic once that list grows beyond a reasonable
> size.  It will replace the list with a flag indicating ALL entries
> may have the characteristic (tested separately).
> 

I noticed, that when I kill the server (using just default kill),
it updates the index files. It seems it does maintain the index
in memory but for some reason doesn't dump it into a file. I do run
with disabled cache writes. Does this option affect the behavior?
Also, is there a way to force index file updates on demand?

> As far as instructions for how to rebuild indexes, see ldbmcat(8)
> and ldif2index(8).  I believe this is covered in the U-Mich guide
> and likely the FAQ.

Also, until I kill the server (and it updates the files) ldbmcat
returns nothing. 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). Are there any other methods?

Thanks,
		Yuri