Re: Load distributed checkpoint

Поиск
Список
Период
Сортировка
От Zeugswetter Andreas ADI SD
Тема Re: Load distributed checkpoint
Дата
Msg-id E1539E0ED7043848906A8FF995BDA5790198ECC8@m0143.s-mxs.net
обсуждение исходный текст
Ответ на Re: Load distributed checkpoint  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Ответы Re: Load distributed checkpoint  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Список pgsql-hackers
> > One thing I do worry about is if both postgresql and the OS
> > are both delaying write()s in the hopes of collapsing them
> > at the same time.  If so, this would cause both to be experience
> > bigger delays than expected, and make checkpoints worse.
>
> That is my concern.  Letting 30 seconds worth of dirty pages
accumulate
> between checkpoints and then trying to smooth the writes within
> checkpoint code seems like a doomed effort.

30 seconds ??? You are supposed to avoid excessive checkpoints.
If you are reducing checkpoint_timeout to avoid the spike, you are imho
definitely tuning the wrong knob. You are supposed to increase
checkpoint_timeout as far as you can to still have an acceptable
recovery delay after a crash.

If you cannot afford a huge spike during checkpoint, say every 30
minutes,
you have to make bgwriter more aggressive. This would generally be true
for
both of the variants, db driven direct io and buffered filesystem io.

Andreas


В списке pgsql-hackers по дате отправления:

Предыдущее
От: DANTE Alexandra
Дата:
Сообщение: PostgreSQL 8.2 : regression failures on IA-64
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Grouped Index Tuples