[Date Prev][Date Next]
Memory leak in 2.4.31 w/ hdb and MMR?
- To: openldap-technical <firstname.lastname@example.org>
- Subject: Memory leak in 2.4.31 w/ hdb and MMR?
- From: Brandon Hume <email@example.com>
- Date: Fri, 18 May 2012 15:15:31 -0300
- User-agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:126.96.36.199) Gecko/20110417 Lightning/1.0b2 Thunderbird/3.1.4
I've got my two-node setup up and running, MMR w/ delta-syncrepl.
Node 1 is up and running with ~340k entries in the main DIT. It
consumes about 4G of VM on a Redhat AS6 box, and the data dir is around
2.3G on-disk (including __db.* and the one log.* file...), and another
100M in cn=accesslog.
I'm bringing up node 2 after nuking the data dir, and letting it
syncrepl from nothing. I was tracking a SIGBUS error, but that turned
out to be olcLogLevel=Stats+Sync generating a huge amount of logging and
filling up the disk. Fixed that, moved on.
Now, it's still crashing... but that's because slapd is bloating up
hugely and causing the machine to run out of VM and kill the process.
I've added about 8G of temporary swap, and it's still going. slapd on
node2 is 5.5G resident, and nearly 15G in size total now. On-disk the
hdb is only around 1.6G, so it still has a long ways to go.
Can I assume this is not the way it should be?
vmstat shows a lot of swap-out but almost no swap-in, so it's not
thrashing. pmap shows a large number of 64M "anon" segments. 140 of
those at one point, and 157 when I checked just now.
It looks a lot like a memory leak, though I can't tell offhand whether
the problem is in OpenLDAP (2.4.31) or in BerkeleyDB (5.3.15). When it
finishes, I'm planning on turning off delta-syncrepl and pave/rebuild
again, and see if it behaves the same. I could also give mdb a shot,
but since this is a mirror I'd have to rebuild both sides.
Any suggestions as to where I could start looking for the source of the
problem? Obviously I'm not planning on rebuilding this node on a
regular basis (and certainly not all via syncrepl) but I'm concerned
that over an extended period of time it'll leak memory even during
I'm including my DB_CONFIG, just in case. I can supply more of the
config as necessary.
set_cachesize 0 536870912 0
(If anything looks particularly stupid in here, even unrelated to the
leak, I'd love the advice...)