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)
Re: Trying to minimize the impact of checkpoints (resend) |
| Список | 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 по дате отправления: