One thing we want to see on the graph is result stability (due to the checkpointing issues) – it would be good idea to ensure the runs we publish have enough run time to write (cycle through) log files 3x or so – this also would show checkpoint dips as several if they present.

One more thing – I’d be careful calling benchmarks CPU bound – I assume you’re speaking “In memory” here – because there are log writes and dirty page flushes from writes there is no guaranty the disk will not be the bottleneck still.

For read only benchmarks in-memory typically means CPU bound but it is not always so for write intensive.

Yes, it was because of checkpointing, you can see more interesting graphs on Sheet “CPUbound”. I will also publish them today.

run was 1200 sec and warmup also 1200 sec

Do you know if the dip in the 5.4 throughput was from checkpointing (i.e, that we could do with the adaptive checkpointing as well)?

Cheer,

Mark

How long was the run ? I see time starts at 0 but it does not have the end.
It is also quite interesting to see xtradb to have some warmup while all other runs seems to have none.