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 | D5A45941-6B93-49F7-848E-5DD17A8F5002@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 Jul 4, 2015, at 11:34 AM, Fabien COELHO <coelho@cri.ensmp.fr> wrote: >>>>> In summary, the X^1.5 correction seems to work pretty well. It doesn't >>>>> completely eliminate the problem, but it makes it a lot better. > > I've looked at the maths. > > I think that the load is distributed as the derivative of this function, that is (1.5 * x ** 0.5): It starts at 0 but veryquicky reaches 0.5, it pass the 1.0 (average load) around 40% progress, and ends up at 1.5, that is the finishing loadis 1.5 the average load, just before fsyncing files. This looks like a recipee for a bad time: I would say this is toolarge an overload. I would suggest a much lower value, say around 1.1... > > The other issue with this function is that it should only degrade performance by disrupting the write distribution if someonehas WAL on a different disk. As I understand it this thing does only make sense if the WAL & the data are on the sameedisk. This really suggest a guc. I am a bit skeptical about this. We need test scenarios that clearly show the benefit of having and of not having this behavior.It might be that doing this always is fine for everyone. ...Robert
В списке pgsql-hackers по дате отправления: