Re: checkpoint patches

On Thu, Mar 22, 2012 at 7:03 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
> On Thu, Mar 22, 2012 at 6:07 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Wed, Mar 21, 2012 at 3:38 PM, Robert Haas <robertmhaas(at)gmail(dot)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.

I didn't stop and restart the server after pgbench -i; it fires off
the test pgbench right after initializing. That seems to provide
enough padding to ensure two checkpoints within the actual run.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company