Re: Expose checkpoint start/finish times into SQL. - Mailing list pgsql-patches

From Robert Treat
Subject Re: Expose checkpoint start/finish times into SQL.
Date
Msg-id 200804032210.52568.xzilla@users.sourceforge.net
Whole thread Raw
In response to Re: Expose checkpoint start/finish times into SQL.  ("Joshua D. Drake" <jd@commandprompt.com>)
Responses Re: Expose checkpoint start/finish times into SQL.
Re: Expose checkpoint start/finish times into SQL.
List pgsql-patches
On Thursday 03 April 2008 21:14, Joshua D. Drake wrote:
> On Thu, 03 Apr 2008 20:29:18 -0400
>
> Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > "Joshua D. Drake" <jd@commandprompt.com> writes:
> > > Heikki Linnakangas <heikki@enterprisedb.com> wrote:
> > >> Why is that useful?
> > >
> > > For knowing how long checkpoints are taking. If they are taking too
> > > long you may need to adjust your bgwriter settings, and it is a
> > > serious drag to parse postgresql logs for this info.
> >
> > 1. To do anything useful along those lines, you would need to look at
> > a lot of checkpoints over time, which is what log_checkpoints is good
> > for. This patch only tells you about the latest, which isn't very
> > useful for making any good decisions about parameters.
>
> I would agree with this. We would need a history of checkpoints that
> didn't reset until we told it to.
>

You can plug a single item graphed over time into things like rrdtool to get
good trending information. And it's often easier to do this using sql
interfaces to get the data than pulling it out of log files (almost like the
db was designed for that :-)

> > 2. If I read the patch correctly, half of the time what you'd be
> > seeing is the start time of the currently-active checkpoint and the
> > completion time of the prior checkpoint.  I don't know what those
> > numbers are good for at all.
>

Knowing when the last checkpoint occured is certainly useful for monitoring
purposes (wrt pitr and as a general item for cuasing alerts if checkpoints
stop occuring frequently enough, or if they start taking too long.)

>
> > 3. As of PG 8.3, the bgwriter tries very hard to make the elapsed time
> > of a checkpoint be just about checkpoint_timeout *
> > checkpoint_completion_target, regardless of load factors.  So unless
> > your settings are completely broken, measuring the actual time isn't
> > going to tell you much.
>

How does one measure when the bgwriter is failing at this effort?

--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL

pgsql-patches by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Expose checkpoint start/finish times into SQL.
Next
From: Tom Lane
Date:
Subject: Re: Expose checkpoint start/finish times into SQL.