On Wed, Dec 23, 2015 at 04:37:00PM +0100, Fabien COELHO wrote: > Hmmm. Let us try with both hands: > > AFAICR with xlog-triggered checkpoints, the checkpointer progress is > measured with respect to the size of the WAL file, which does not > grow linearly in time for the reason you pointed above (a lot of FPW > at the beginning, less in the end). As the WAL file is growing > quickly, the checkpointer thinks that it is late and that it has > some catchup to do, so it will start to try writing quickly as well. > There is a double whammy as both are writing more, and are probably > not succeeding. > > For time triggered checkpoints, the WAL file gets filled up *but* > the checkpointer load is balanced against time. This is a "simple" > whammy, where the checkpointer uses IO bandwith which is needed for > the WAL, and it could wait a little bit because the WAL will need > less later, but it is not trying to catch up by even writing more, > so the load shifting needed in this case is not the same as the > previous case. > > As you point out there is a WAL spike in both case, but in one case > there is also a checkpointer spike and in the other the checkpointer > load is flat.
Coming in late here, but I always thought the fact that the FPW happen mostly at the start of the checkpoint, and the checkpoint writes/fsyncs happen mostly in the first half of the checkpoint period was always suboptimal, i.e. it would be nice of one of these was more active in the second half of the checkpoint period. I assume that is what is being discussed here. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Roman grave inscription + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
