Hi. After the last episode of "killall slapd; db4.2_recover; /etc/init.d/slapd start" my DB_CONFIG looks like this:
#txn_checkpoint 128 15 1 set_cachesize 0 252428800 0 set_lk_max_objects 100000 set_lk_max_locks 100000 # set_lk_max_lockers 100000 # set_lg_regionmax 1048576 set_lg_max 8388608 set_lg_bsize 2097152 set_lg_dir /var/lib/ldap/logs/ #set_lk_detect DB_LOCK_DEFAULT set_tmp_dir /tmp/ #set_flags DB_TXN_NOSYNC #set_flags DB_TXN_NOT_DURABLE Note the enormous amount of possible locks, lockers and lockable objects. So far, only increasing this amount seems to be the way to circumvent the dreaded sched_yield()-loop. My last change is set_lk_max_lockers 100000 which was still default and seems to be to _real_ culprit, as per ITS#2030: http://www.openldap.org/its/index.cgi/Software%20Bugs?id=2030;selectid=2030;usearchives=1 (Note how old this bug report to the OpenLDAP ITS is.) Right now I am running some stress tests on my systems, but those %$/&%$§ bastards never locked up, when I was actively trying to push them over the edge. It would be really helpful, if anybody experiencing those problems could check with increased locker-settings (as seen above) if they still have that problem. Grüße, Sven. -- Sven Hartge -- professioneller Unix-Geek und alltime Nerd Meine Gedanken im Netz: http://sven.formvision.de/blog/
