Re: Controlling Load Distributed Checkpoints
Hannu Krosing <hannu@skype.net>
From: Hannu Krosing <hannu@skype.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Heikki Linnakangas <heikki@enterprisedb.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>, ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp>, Greg Smith <gsmith@gregsmith.com>
Date: 2007-06-07T09:28:03Z
Lists: pgsql-hackers
Ühel kenal päeval, K, 2007-06-06 kell 11:03, kirjutas Tom Lane: > Heikki Linnakangas <heikki@enterprisedb.com> writes: > > GUC summary and suggested default values > > ---------------------------------------- > > checkpoint_write_percent = 50 # % of checkpoint interval to spread out > > writes > > checkpoint_write_min_rate = 1000 # minimum I/O rate to write dirty > > buffers at checkpoint (KB/s) > > checkpoint_nap_duration = 2 # delay between write and sync phase, in > > seconds > > checkpoint_fsync_period = 30 # duration of the sync phase, in seconds > > checkpoint_fsync_delay = 500 # max. delay between fsyncs > > > I don't like adding that many GUC variables, but I don't really see a > > way to tune them automatically. > > If we don't know how to tune them, how will the users know? He talked about doing it _automatically_. If the knobns are available, it will be possible to determine "good" values even by brute-force performance testing, given enough time and manpower is available. > Having to > add that many variables to control one feature says to me that we don't > understand the feature. The feature has lots of complex dependencies to things outside postgres, so learning to understand it takes time. Having the knows available helps as more people ar willing to do turn-the-knobs-and-test vs. recompile-and-test. > Perhaps what we need is to think about how it can auto-tune itself. Sure. ------------------- Hannu Krosing