Re: Log levels for checkpoint/bgwriter monitoring

From: Greg Smith <gsmith(at)gregsmith(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Log levels for checkpoint/bgwriter monitoring
Date: 2007-03-10 00:56:54
Message-ID: Pine.GSO.4.64.0703091936030.9297@westnet.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, 9 Mar 2007, Tom Lane wrote:

> I'd be interested to know what scale factor and shared_buffers setting
> led to the above measurement.

That was just a trivial example with 1 client, scale=10 (~160MB database),
and shared_buffers=24MB. Where things really get interesting with pgbench
is on a system with enough horsepower+clients to dirty the whole buffer
cache well before a checkpoint. I regularly see >75% of the cache dirty
and blocked from LRU writes with pgbench's slightly pathological workload
in that situation.

You're correct that these results aren't particularly surprising or
indicative of a problem to be corrected. But they do shed some light on
what pgbench is and isn't appropriate for testing.

> It strikes me that the patch would be more useful if it produced a
> histogram of the observed usage_counts, rather than merely the count
> for usage_count = 0.

I'll start working in that direction. With the feedback everyone has
given me on how few of the buffers are truly "pinned" via the correct
usage of the term, I'm going to revisit the usage details and revise that
section. I'm happy with how I'm reporting the checkpoint details now,
still some work left to do on the bgwriter activity.

--
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Gregory Stark 2007-03-10 01:05:31 Re: Bug in VACUUM FULL ?
Previous Message Matthew T. O'Connor 2007-03-10 00:49:43 Re: autovacuum next steps, take 3