Hi,
It seems we've hit the same bug here: we had to reboot our server twice,
and upon restart, slapd went into just the same sched_yield() loop with
the same backtrace. Running db4.2_recover worked fine to correct things
while LD_ASSUME_KERNEL=2.4 didn't help. Our system is really far from
being
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 2524288000
Um 02:29 Uhr am 16.04.05 schrieb Steve Langasek:
#txn_checkpoint 128 15 1
set_cachesize 0 2524288000
set_lk_max_objects 10
set_lk_max_locks10
#
set_lk_max_lockers 10
#
set_lg_regionmax1048576
set_lg_max
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 10
which was still default and seems to be to _real_ culprit, as per
ITS#2030:
4 matches
Mail list logo
