Trying to minimize the impact of checkpoints (resend)

Поиск
Список
Период
Сортировка
От jao@geophile.com
Тема Trying to minimize the impact of checkpoints (resend)
Дата
Msg-id 1086983714.40ca0e22a9cb4@geophile.com
обсуждение исходный текст
Ответы Re: Trying to minimize the impact of checkpoints (resend)  (Doug McNaught <doug@mcnaught.org>)
Re: Trying to minimize the impact of checkpoints (resend)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-general
[Sorry if this is a repeat. I think the first message may have
been rejected due to an attachment.]

I'm using PostgreSQL 7.3.4 on RH9. Data and logs are on separate
disks. (These are low-end IDE disks. That part of the problem
is out of my control.)

When a checkpoint occurs, all operations slow way, way down.
iostat of the data disk shows that, during a checkpoint, reads/sec
drops from 25-30 to under 0.5. Writes/sec go up, from 40-45
before the checkpoint, to 80-85 during. My test program does
a mixture of 1/2 reads and 1/2 inserts, so it basically comes
to a stop during checkpoints.

What can I do about this? The variability in read and insert times is
really hurting us. I know how to make checkpoints less frequent. I
know that the background writer will show up in 7.5. But what can I do
now?

Does anyone have any experience in modifying the priority of the
checkpoint process itself, (re-nicing it)?

- Would this be effective in slowing down checkpointing, allowing
concurrent work to get done more quickly?

- Is this a dangerous thing to do?

- How would it be done? (From outside postgresql if possible, but
we'll tweak the source if necessary.)

Jack Orenstein

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

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

Предыдущее
От: Josué Maldonado
Дата:
Сообщение: Set returning functions and Crystal Reports
Следующее
От: Doug McNaught
Дата:
Сообщение: Re: Trying to minimize the impact of checkpoints (resend)