Trying to minimize the impact of checkpoints (resend) - Mailing list pgsql-general

From jao@geophile.com
Subject Trying to minimize the impact of checkpoints (resend)
Date
Msg-id 1086983714.40ca0e22a9cb4@geophile.com
Whole thread Raw
Responses 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>)
List 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 by date:

Previous
From: Josué Maldonado
Date:
Subject: Set returning functions and Crystal Reports
Next
From: Doug McNaught
Date:
Subject: Re: Trying to minimize the impact of checkpoints (resend)