From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
Cc: | Dan Armbrust <daniel(dot)armbrust(dot)list(at)gmail(dot)com>, pgsql general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Checkpoint Tuning Question |
Date: | 2009-07-10 16:14:13 |
Message-ID: | 24463.1247242453@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> I think its a traffic jam.
> After checkpoint in XLogInsert(), we discover that we now have to backup
> a block that we didn't think so previously. So we have to drop the lock
> and then re-access WALInsertLock. So every backend has to go through the
> queue twice the first time it tries to write WAL immediately after a
> checkpoint. Also, suddenly, every block needs to be copied to WAL, so
> the CRC checks make each lock holder take longer than normal, so the
> whole queue begins to backup. Then, because of wal_buffers being small
> we find that the increased volume of WAL being written causes
> WALInsertLock to be held across I/O.
Hm, I'm not sure I believe any of that except the last bit, seeing that
he's got plenty of excess CPU capability. But the last bit fits with
the wimpy-I/O problem, and it also offers something we could test.
Dan, please see what happens when you vary the wal_buffers setting.
(Note you need a postmaster restart to change that.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Brandon Metcalf | 2009-07-10 16:16:10 | UNION question |
Previous Message | Simon Riggs | 2009-07-10 15:39:49 | Re: Checkpoint Tuning Question |