[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: slapd grows without bounds
Hi,
I asked about this already, but I found a new thread
that is relevant.
I am running into the same problem as the original poster,
the difference being that I am using Berkeley DB 2.7.7
rather than 1.85.
I have only 1500 entries and the following indexes:
index dn,mailhost,mail,mailalternateaddress eq
My process size will grow to 250 megs or more and then
die on failed on realloc. Setting cachesize and dbcachesize
has no effect.
250 megs for 1500 entries does not seem reasonable - this
was happening even before I added the indexes, so indexing
isn't my problem.
There a others who are having the same problem with both
Linux and FreeBSD, and nobody I talked to has ever found
a solution.
Can anyone shed some light on this?
Dave
At 10:49 AM 1/30/00 -0500, wesley.craig@umich.edu wrote:
>>> From: George Cox <gjvc@extremis.demon.co.uk>
>>> To: openldap-software@OpenLDAP.org
>>
>>> Well, the subject says it all really. I have OpenLDAP 1.2.9,
PerlDAP 1.4,
>>> and the Netscape Directory SDK for C on FreeBSD 4.0-CURRENT. The
>>> underlying ldbm is Berkeley DB 1.85.
>>
>>First, the Netscape Directory SDK is LDAPv3, while OpenLDAP 1.2.9 is
>>LDAPv2.
>
>The Netscape (Mozilla) SDK interoperates with OpenLDAP 1.x without
>any problems as long as you stick to LDAPv2 operatons.
>>This is probably not your current problem, but it could cause
>>problems with any code you write with it.
>The semantics of some API calls a bit difference... be sure to
>use their manual, not our ours, when programming with their
>API.
>>OpenLDAP 1.2.9 should be run with Berkeley DB 2.7.7.
>>There's a good chance that this is your size problem.
>
>Likely the size problem is just unexpected cache growth.
>
>>> Initially, I cooked up an LDIF file with 20,000 records, ran
ldif2ldm and
>>> made queries using my PerlDAP-based scripts.
>>
>>ldif2ldbm should not be used to initially load the database. Instead,
>>the server should be started with scheme checking turned on and
ldapadd
>>should be used.
>
>Very true.
>
>>> Every query, be it light- or
>>> heavy-weight resulted in the slapd process increasing in size until
it took
>>> up 140M or thereabouts and I killed it.
>>
>>140M could be fine, depending on the number of indexes you've
>>configured slapd to build and how large you've configured the caches
to
>>be. The server I run, with 25 indexes and and 10M caches, is at 170M
>>right now. Another server, similarly configured, is in excess of
350M,
>>tho it's been running for a month.