Hi Sven, On Mon, Apr 11, 2005 at 11:56:23PM +0200, Sven Hartge wrote:
> 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.) 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? Has the database held up under stress after making these changes? 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. Thanks, -- Steve Langasek postmodern programmer
signature.asc
Description: Digital signature
