Right. Larger delay should cause less work to do. In fact you can come up with cases when delaying writes 10 times will cause 10 less amount of writes being done.

With innodb_max_dirty_pages_pct the story is different – it is working as expected. If you allow system to keep fewer pages dirty this means you can’t delay writes for as much (some of dirty pages will be flushed because of LRU instead of delayed more). With results for adaptive_flushing however I see very unexpected behavior.

I think there is actually a “bug” in the adaptive flushing in Innodb – it just does it too eagerly.

I think if I specify log files of 2GB (with no other way to specify how long I’d like to delay my writes) Innodb should try to minimize amount of flushes it does using the provided 2GB of the log space. It is not happening here – instead it flushes a lot – as we can see it does probably 3x more flushes than it could (disabled adaptive flushes does not cause any blips in this case)

There is indeed a good point about Pay Per IO storage as well as SSDs (which also “cost” you per IO as more writes you do the more quickly it will wear out) may benefit from modified flush policy which does not try to utilize idle bandwidth as much but rather use “write combining” to the maximum.