Re: slapd eating up resource on 2.3.14

[Howard Chu <hyc@symas.com>]

Quanah Gibson-Mount wrote:
> --On Friday, January 06, 2006 2:27 PM -0500 "Allan E. Johannesen" 
> <aej@WPI.EDU> wrote:
>
> > > > > > > "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
>
> 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/