RE: slapd eating up resource on 2.3.14

["Allan E. Johannesen" <aej@WPI.EDU>]

>>>>> "aej" == Allan E Johannesen <aej@WPI.EDU> writes:

aej> 2.3.15 also runs fine for the first thousand queries, but then bogs down.
aej> There were several changes to ...bdb/cache.c in 2.3.14, and that file is
aej> identical in 2.3.15.  I sort of suspect the problem is there, but I
aej> haven't the knowledge of the internals, nor the knowledge of Berkeley db
aej> locking, to figure it out.

I put a bunch of "Debug()" displays into servers/slapd/back-bdb/cache.c in
2.3.13 and 2.3.14.

At about a thousand client queries, 2.3.14 shows a loop in
bdb_cache_lru_purge(), a new routine, which was mainly excised from
bdb_cache_lru_add() in 2.3.13.

Since I only put the Debug()'s in after lock() and unlock() calls, I only see
that activity.  At this point in 2.3.14, there are 935 (in my test) repetitions
of

bdb_cache_lru_purge: bdb_cache_entry_db_lock( bdb->bi_dbenv, bdb->bi_cache.c_locker, elru, 1, 1, lockp )
bdb_cache_lru_purge: bdb_cache_entry_db_unlock( bdb->bi_dbenv, lockp )

A similarly long loop does not appear in the test run of 2.3.13.  There are
occasional single appearances of the pairs

bdb_cache_lru_add: bdb_cache_entry_db_lock( bdb->bi_dbenv, bdb->bi_cache.c_locker, elru, 1, 1, lockp )
bdb_cache_lru_add: bdb_cache_entry_db_unlock( bdb->bi_dbenv, lockp )

in the 2.3.13 run, but not a long repetition like the 2.3.14 run showed.  After
that loop, response is slow and slapd eats lots of CPU.

In the overall debug output (slapd -d1), the first call to the routine appears
at about line 101,000 in both cases, but in the 2.3.14 case, there is a loop of
lock/unlocks, but only single instances sprikled through the 2.3.13 case.

Unless there was a decision to change behavior, which would result in this
different activity, I think there's some sort of problem in the development of
bdb_cache_lru_purge() from the former 2.3.13 source...