Quanah Gibson-Mount wrote:
--On Friday, January 06, 2006 2:27 PM -0500 "Allan E. Johannesen"
<[EMAIL PROTECTED]> wrote:
"aej" == Allan E Johannesen <[EMAIL PROTECTED]> 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
As I already reported yesterday in a follow up, this particular bug
has been fixed, and will be in the upcoming 2.3.16 release.
One specific issue was fixed, and Kevin has reported that with the fix
the performance is comparable to 2.3.13. (Fix is in CVS, will be in
2.3.16) But Allan's note highlights another behavioral change in this
same code:
Up to 2.3.13, when the entry cache was full, at most 10 entries were
examined to find one to free (and would give up if it couldn't find an
unused cache entry in those 10 tries). In 2.3.14, with the purge being
handled in a separate thread, the loop will examine as many entries as
necessary until it frees enough entries. That's why you'll see more
lock/unlock calls in the debug traces.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/
