Um 23:56 Uhr am 11.04.05 schrieb Sven Hartge: [Sorry for spamming this bug report, but I _really_ need to get this going *fast*.]
> 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.) After torturing my setup with different scripts and trying to to rebuild the normal workload, I am confident, after having run watch -n1 -d "db4.2_stat -c" for some time in parallel, the sched_yield() loop occurs, because the bdb-backend runs out of lockers. At least this is what I get from ITS#2030 and from various other resources (mostly documentation from Sleepycat). So I suggest for the package to create a DB_CONFIG with _at least_ 5000 lockers, locks and lock objects. The default of 1000 is just to low and will get exploitet in no time by even a little database. (Don't close this bug yet, further observation has to happen.) Grüße, Sven. -- Sven Hartge -- professioneller Unix-Geek und alltime Nerd Meine Gedanken im Netz: http://sven.formvision.de/blog/
