[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: slapd eating up resource on 2.3.14



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/