Um 02:29 Uhr am 16.04.05 schrieb Steve Langasek: >> #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.
>> 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.) > The last follow-up in that ITS points to > <http://www.sleepycat.com/docs/ref/lock/max.html>, which gives > guidelines about how to tune the number of available locks and lockers. > Is this what you did? Correct. But since I desperately needed the databases (after all, this are my production LDAP servers), I upped the number to this very high value, so they would hold up in an case, without me manualle rebuilding the database every 6 to 12 hours. I am about to lower this to 10000, since 100000 is just to high for my workload, consuming to much memory. > Has the database held up under stress after making these changes? Yes, after the changes, I experienced no more lookups or database corruptions. > I'm not sure how useful it is to set a fixed number of lockers by > default, since the optimal value depends on usage statistics; but > bumping from 1000 to 5000 doesn't seem like it can hurt much. 1000 seems to low in most cases, at least my experience show this. But: I still consider it a grave bug for db4.2, if running out of lockers corrupts the database. And I consider it a bug in slapd, if it runs into a busy-waiting loop, if something inside the database went wrong. Grüße, Sven. -- Sven Hartge -- professioneller Unix-Geek und alltime Nerd Meine Gedanken im Netz: http://sven.formvision.de/blog/
