[Date Prev][Date Next]
Memory leak or index corruption?
- To: openldap-bugs@OpenLDAP.org
- Subject: Memory leak or index corruption?
- From: Tom Poage <firstname.lastname@example.org>
- Date: Tue, 15 Apr 2003 11:35:30 -0700
- User-agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0
This has been a problem for the last handful of releases (through
I run a simple "whitepages" server: simple authentication (no SASL,
etc.) for a small number of updates performed daily on the local
machine by the directory manager. All outside queries use anonymous
binds (virtually all coming from a CGI script using Net::LDAP).
Solaris 8, gcc 3.2, Berkeley DB 2.1.15, configuration:
--enable-wrappers --enable-phonetic --enable-rewrite
--enable-meta --enable-ldap --enable-rlookups --enable-ldbm
For BDB I've set cachesize in DB_CONFIG to 50 MB. The .bdb files
themselves consume approx. 300 MB.
There is a single one-way suffix rewriting rule to accomodate an
old-style search base (<OLDBASE>):
rewriteRule "(.*)<OLDBASE>" "%1<NEWBASE>" ":"
A couple of access-control entries attempt to keep some information
access to dn="<NEWBASE>" attrs=<attr1>,<attr2>,...
by peername="^IP=XXX\.YYY\." read
by peername="^IP=127\.0\.0\.1:[0-9]+$$" read
by anonymous search
access to *
by * read
On starting slapd, memory will climb a bit and level off at somewhere
around 60MB-100MB. After approx. one day (about 20k-40k queries), memory
use starts to expand and then queries become very slow (an execution trace
indicates that indexes are no longer being used). If it continues, the
system eventually exhausts VM and slapd crashes.
A dump of a live slapd's memory map while this is happening shows that the
'leak' is on the heap.
This happens whether I build the db/run with bdb or ldbm (the 'other' BDB).
I do note that not all query connections log an UNBIND before terminating
Before I dive in to add/modify a bunch of memory debugging test code
(with time I don't have at the moment), has anyone seen this behavior?
Any hints for working around the problem?