From my many years of Informix knowledge, we noticed that checkpoints,
during high activity times, did take a long time, because it locked the
shared memory segment. We found that setting the checkpoint knobs to flush
almost constantly, overall, was much better for performance.
Looking in postgresql.conf, it seems that some tweaking of :
CHECKPOINT_SEGMENTS and CHECKPOINT_TIMEOUT are in order.
I also see some interesting items in the WAL_* configuration parameters,
and would look at these as well. Again, in Informix-speak, we were able to
control when the buffers flushed to disk, with parameters like:
Start flushing buffers when they are X% full
and keep flushing until they are X% full
Overall, having TONS of buffers helped benchmark performance, but could
have slowed down checkpoints had we not continually flushed to disk.
At 11:37 AM 4/10/02 -0400, Tom Lane wrote:
>Raphael Bauduin <raphael@be.easynet.net> writes:
> > At some times, it seems to hang: it doesn't insert any rows for more
> > than 10 seconds. At that time, the postmaster process takes 0%. Why is
> > that?
>
>At a guess, you're seeing the syncer daemon flushing a lot of dirty
>kernel disk buffers out to disk, and thereby monopolizing disk I/O.
>I haven't experimented too much with Linux, but on HPUX it's not
>difficult for a sync() call to bring the system to its knees for many
>seconds, if you've got application programs that have written a whole
>lot of pages since the last sync.
--
Naomi Walker
Chief Information Officer
Eldorado Computing, Inc.
602-604-3100 ext 242
