> 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
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().