Paul Turgyan wrote:
We've seen the slapd's on our mail slaves trying to grow greater than the 2 gigabyte resident set size. I spent two days w/ valgrind looking for memory leaks, but I failed to find anything. I finally discovered that repeatedly binding and unbinding using a SASL/ GSSAPI bind would cause slapd's resident set size and vm size to grow. So I wrote a test program to SASL Bind, issue a search, and unbind. The test program would do this sequence 10000 times before it stopped. The test program always issues the same exact search trying to eliminate any interferance from a growing entry cache and/or idlcache.
If valgrind doesn't show anything then you're going to have to get more invasive. One possibility is to test again with a stripped down configuration. Just measure the memory use from a single Bind and Unbind, with no search operation in between. Or just query the rootDSE. You can test this with a practically empty slapd.conf file (since the config database always exists).
Change the slapd shutdown handler to just call exit() immediately. That will prevent anything from cleaning up. It will give valgrind plenty of leaks to complain about. Compare a session using a single anonymous bind vs a session using a single SASL/GSSAPI bind. That will show you where the discrepancy in memory use came from.