From: Kevin Lewis
Date: January 28 2009 4:52am
Subject: Re: The Reluctant Scavenger
List-Archive: http://lists.mysql.com/falcon/431
Message-Id: <497FE48A.30403@sun.com>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset=ISO-8859-1
Content-Transfer-Encoding: 7BIT

 > Christopher Powers wrote:
> I'm running the testcase for Bug #36442. What do you make of this?
> 
> Cycle=3157  Base Generation=1  Scavenge Generation=0
> Cycle=3157  Oldest Active Transaction=6514
> Cycle=3157  Threshold=175636480  Floor=87818240  Now=177545672
> Cycle=3157  Age=1  Size=177543696
> Cycle=3157  Very Old Records=0 Size=0
> Cycle=3157  Inventory; Total records=296226 containing 177545936 bytes
> Cycle=3157  Inventory; Pruneable records=3 containing 1104 bytes
> Cycle=3157  Inventory; Retireable records=296215 containing 177541392 bytes
> Cycle=3157  Inventory; unScavengeable records=8 containing 3440 bytes
> Cycle=3157  Results; Pruned 3 records, 1104 bytes in 1 seconds
> Cycle=3157  Results; Retired 0 records, 0 bytes in 0 seconds
> Cycle=3157  Results; Remaining 296223 Records, 177544832 remaining bytes
> Cycle=3157  Results; Active memory at Scavenge Start=177545688
> Cycle=3157  Results; Active memory after Pruning Records=177544840
> Cycle=3157  Results; Active memory after Retiring Records=177545672

Hey Chris,  It's a lot of information in this new scavenger report, huh?

During the pruning cycle, RecordScavenge::inventoryRecords() will take a 
survey to see how many records and bytes could possibly be retired. 
That number is here.

Inventory; Retireable records=296215 containing 177541392 bytes

Since 177,544,840 bytes is more than the threshold of 175,636,480 bytes 
after pruning, this scavenge cycle would have tried to retire records. 
But the requirements for actually retiring records, determined in 
RecordScavenge::canBeRetired(), are a little stiffer than during the 
inventory.  That is because the inventory is trying to find how much 
memory we could possibly save, and what age groups they are in.  Since 
these are two different passes through the record tree, things can 
change between them.  In the inventory stage, the records need only to 
be committed before any active transaction to be retirable.  But to 
actually be retired, they need to be separated from their transaction 
object.

So my only guess here is that all those 'retireable' records cannot 
actually be retired because the transactions are still hanging around. 
But I don't know why that would be...  And this is a lot of records to 
still be linked to transactions.

You should put a break in RecordScavenge::canBeRetired().