On Thu, Mar 22, 2012 at 7:03 PM, Jeff Janes <jeff.ja...@gmail.com> wrote: > On Thu, Mar 22, 2012 at 6:07 AM, Robert Haas <robertmh...@gmail.com> wrote: >> On Wed, Mar 21, 2012 at 3:38 PM, Robert Haas <robertmh...@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.
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
