Re: Let PostgreSQL's On Schedule checkpoint write buffer smooth spread cycle by tuning IsCheckpointOnSchedule?
От | Robert Haas |
---|---|
Тема | Re: Let PostgreSQL's On Schedule checkpoint write buffer smooth spread cycle by tuning IsCheckpointOnSchedule? |
Дата | |
Msg-id | CA+TgmoZVrRg7O6tU-HNcGQKH-5ciO1wZDom-VfLwTa9v-9CeFA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Let PostgreSQL's On Schedule checkpoint write buffer smooth spread cycle by tuning IsCheckpointOnSchedule? (Fabien COELHO <coelho@cri.ensmp.fr>) |
Ответы |
Re: Let PostgreSQL's On Schedule checkpoint write buffer
smooth spread cycle by tuning IsCheckpointOnSchedule?
|
Список | pgsql-hackers |
On Wed, Dec 23, 2015 at 10:37 AM, Fabien COELHO <coelho@cri.ensmp.fr> 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. I see your point, but this isn't a function of what triggered the checkpoint. It's a function of how we measure whether the already-triggered checkpoint is on schedule - we may be behind either because of time, or because of xlog, or both. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: