Most likely you're running into heap fragmentation problems with the default C library malloc() function. For example, see my malloc benchmarking results http://highlandsun.com/hyc/malloc/
The newer code in OpenLDAP 2.4 will delay the onset of this problem, but the only sure way to eliminate it is to either tune the malloc library (see the mallopt manpage) or replace it (using libhoard or libtcmalloc, typically).
Johan Jönemo wrote:
I have made a test package to see if people understanding openLDAP better than I do can reproduce and possibly explain the strange behavior I have been plagued by.
I run an application that updates a directory more or less continuously and it runs at a reasonable speed. Often this can last for hours. Then everything slows down drastically (by more than a factor 10) in one instant (i e it doesn't slow down gradually). I think that slapd spends long times in some kind of waiting state. I base this on the fact that I can induce the behaviour regardless of which of a large number of methods I have tried on the "client" side, i e the application updating the directory. I have tried calling the ldap client tools from shell scripts and using the API with perl bindings and so on. The WCHAN seem to be the same most of the time that te application is slow. Unfortunately I wasn't able to make any sense of this numerical information (I'm not too familiar with kernels and such).
I have got this behaviour with different versions of openLDAP I have tried (the newest being 2.3.32). Different Berkley db packages in the range 4.3-4.5 didn't seem to matter. The instructions for the package can be found at:
http://www.hep.lu.se/staff/jonemo/README.txt
And the test package itself at:
http://www.hep.lu.se/staff/jonemo/cached-dryrun.tar.bz2
It does a none intrusive set-up in order to set some paths but it doesn't copy anything to outside its own directory. It starts an instance of the local slapd on a non-standard port using its own configuration and schema.
I would be very interested if anyone would try out this package and see if they can explain the behavior (or reproduce it at all, as the case may be).
Thanks in advance
Johan Jönemo