On Thu, Mar 22, 2012 at 6:07 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Wed, Mar 21, 2012 at 3:38 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> It looks like I neglected to record that information for the last set
>> of runs. But I can try another set of runs and gather that
>> information.
>
> OK. On further review, my previous test script contained several
> bugs. So you should probably ignore the previous set of results. I
> did a new set of runs, and this time bumped up checkpoint_segments a
> bit more, in the hopes of giving the cache a bit more time to fill up
> with dirty data between checkpoints. Here's the full settings I used:
>
> shared_buffers = 8GB
> maintenance_work_mem = 1GB
> synchronous_commit = off
> checkpoint_timeout = 15min
> checkpoint_completion_target = 0.9
> wal_writer_delay = 20ms
> log_line_prefix = '%t [%p] '
> log_checkpoints='on'
> checkpoint_segments='1000'
> checkpoint_sync_pause='3' # for the checkpoint-sync-pause-v1 branch only
>
> With that change, each of the 6 tests (3 per branch) involved exactly
> 2 checkpoints, all triggered by time rather than by xlog.
Are you sure this is the case? If the server was restarted right
before the pgbench -T 1800, then there should 15 minutes of no
checkpoint, followed by about 15*0.9 minutes + some sync time of one
checkpoint, and maybe just a bit of the starting of another
checkpoint. If the server was not bounced between pgbench -i and
pgbench -T 1800, then the first checkpoint would start at some
unpredictable time into the benchmark run.
Cheers,
Jeff