Re: Add usage counts to pg_buffercache - Mailing list pgsql-patches

From Bruce Momjian
Subject Re: Add usage counts to pg_buffercache
Date
Msg-id 200704030123.l331N5111381@momjian.us
Whole thread Raw
In response to Add usage counts to pg_buffercache  (Greg Smith <gsmith@gregsmith.com>)
List pgsql-patches
Your patch has been added to the PostgreSQL unapplied patches list at:

    http://momjian.postgresql.org/cgi-bin/pgpatches

It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.

---------------------------------------------------------------------------


Greg Smith wrote:
> This patch adds the usage count statistic to the information available in
> contrib/pgbuffercache.  Earlier this month a discussion about my first
> attempt to instrument the background writer had Tom asking for details
> about the usage histogram I was seeing, and this patch proved to be the
> easiest way I found to take a look at that.
>
> In situations where one is trying to optimize the background writer, it's
> very hard to adjust how much to rely on the LRU writer versus the one that
> writes everything unless you know whether your dirty buffers are typically
> used heavily (like index blocks) or not (like new INSERT data).  Some
> statistics about the usage counts in your buffer cache are extremely
> helpful in making that decision.
>
> I'll even pass along an ugly but fun query that utilizes this.  The
> following will give you a summary of your buffer cache broken into 32
> sections.  Each line shows the average usage count of that section, as a
> positive number if most buffers dirty and a negative one if most are
> clean.  If you refresh this frequently enough, you can actually watch
> things like how checkpoints move through the buffer cache:
>
> SELECT current_timestamp,
> -- Split into 32 bins of data
> round(bufferid / (cast((select setting from pg_settings where
> name='shared_buffers') as int) / (32 - 1.0)))
> as section, round(
> -- Average usage count, capped at 5
> case when avg(usagecount)>5 then 5 else avg(usagecount) end *
> -- -1 when the majority are clean records, 1 when most are dirty
> (case when sum(case when isdirty then 1 else -1 end)>0 then 1 else -1
> end)) as color_intensity
> FROM pg_buffercache GROUP BY
> round(bufferid / (cast((select setting from pg_settings where
> name='shared_buffers') as int) / (32 - 1.0)));
>
> The 32 can be changed to anything, that's just what fits on my screen.
> The main idea of the above is that if you dump all this to a file
> regularly, it's possible to produce a graph of it showing how the cache
> has changed over time by assigning a different color intensity based on
> the usage count--at a massive cost in overhead, of course.  I'll be
> passing along all that code once I get it ready for other people to use.
>
> --
> * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
Content-Description:

[ Attachment, skipping... ]

>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
>                http://archives.postgresql.org

--
  Bruce Momjian  <bruce@momjian.us>          http://momjian.us
  EnterpriseDB                               http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

pgsql-patches by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: index support is NULL
Next
From: Bruce Momjian
Date:
Subject: Re: Logging checkpoints and other slowdown causes