Closed caetanosauer closed 8 years ago
Hi Max,
it seems weird that a scale factor of 2 with 8 workers is being picked by default. The default options should be SF 1 with 4 workers.
But of course, this is no excuse. There's probably something wrong in the kits loader code. We can see that in the line "Finished loading units 2100 .. 2000" -- this obviously doesn't make sense, because the units should only go up to 2000, and the first number should always be smaller than the second.
I'm checking this further now.
Fixed in master. Please rebase your branch.
From @iMax3060 on April 17, 2016 0:16
The scale factor and the number of workers wasn't a problem here. I executed the benchmark several times with different parameters and just picked one output as an example. But I had the same issue (the assertion failure) in the most times I executed the program independently from which parameters I have chosen. And I still get the assertion failure as described.
Could you get a stack trace with gdb? Just run:
gdb --args zapps kits ...
When the assertion failure happens, you can type backtrace
or just bt
in the console.
It looks like pages are being evicted with dirty updates, causing single-page recovery, which then fails. There's a bug with recovery that I'm currently trying to fix -- this may be related to that.
I just got this assertion failure myself -- working on it now
This failure is happening very rarely for me, but so far I manager to narrow it down to a bug in the page cleaner in combination with instant restart and single-page recovery. If it's bothering you, I think setting --sm_cleaner_ignore_metadata true
should make it go away for now. Alternatively, you can disable instant restart with --sm_restart_instant false
I will try to fix this and other bugs over the week.
Fixed in f16e5e7, now in master
From @iMax3060 on April 14, 2016 22:35
Sometimes when executing
zapps kits -b tpcc --duration 30 --load
with/without other parameters I get the following output:Copied from original issue: iMax3060/zero#1