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@gregsmith.com http://www.gregsmith.com Baltimore, MD