On Mon, 24 Aug 2009, Aaron Richton wrote:
What does this look with top and/or in dmesg over the run time? Is it a simple out-of-memory? Definitely a bit of a gross method, but what's ls -lh core show for size?
I haven't been able to monitor it constantly over its lifespan, as it takes anywhere from 24 to 36 hours of our load before failure, but what I have observed is that slapd continually grows (slowly) over the course of the test until it can't malloc any more. Core sizes run around 640Mb. The largest '__db' element is 1.9Gb.
So, slapd behaves as if there's a slow memory leak, somewhere. Unless the delta syncrepl mechanism (on producer) has an insatiable memory appetite. Our test suite is heavy on updates, including mods to large-memeber groups (with 120K+ members).
The consumer slapd never dies, and more or less keeps up with the change load from the producer.
(If so, is it warranted given your load or is there a leak, etc etc...and of course make sure you're up to date on the surrounding packages, OpenLDAP isn't the only thing that can leak.)
openldap-2.4.17 db-4.7.25 (patch level 4) openssl 0.9.8e Red Hat Enterprise Linux Server release 5.4
Tracy