Re: Details about pg_stat_bgwriter

From: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>
To: Greg Smith <greg(at)2ndquadrant(dot)com>
Cc: Thomas Kellerer <spam_eater(at)gmx(dot)net>, pgsql-admin(at)postgresql(dot)org
Subject: Re: Details about pg_stat_bgwriter
Date: 2010-06-09 06:02:09
Message-ID: AANLkTink6aRAdHYmpKy_M_m7uw35kl69jbjitOkd5QiQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

On Tue, Jun 8, 2010 at 11:14 PM, Greg Smith <greg(at)2ndquadrant(dot)com> wrote:
> Greg Smith wrote:
>>
>> You don't much with a single snapshot of pg_stat_bgwriter data.  Try
>> saving this instead:
>> select *,now() from pg_stat_bgwriter;
>> And then take another snapshot at least a few hours later, preferably the
>> next day.  With two snapshots and timestamps on them, then it's possible to
>> make some sense of the numbers.
>
> I probably should have explained the next part.  I've now shared what I do
> with this information at
> http://www.pgcon.org/2010/schedule/events/218.en.html
>
> Basically, if you put the data from the two snapshots into one of the
> Statistics Spreadsheet versions, you'll get several derived numbers that pop
> out:
>
> -Average checkpoint frequency
> -Average size of each checkpoint
> -Average rate at which new buffers are allocated
> -Average rate of writes out of the buffer cache
> -Percentage of writes done by checkpoints, the background writer LRU
> cleaner, and client backends

I think you get all or most of that if you just log checkpoints.

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Greg Smith 2010-06-09 06:04:04 Re: optimizer behavior in the case of highly updated tables
Previous Message Scott Marlowe 2010-06-09 05:54:27 Re: optimizer behavior in the case of highly updated tables