From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Figuring out shared buffer pressure |
Date: | 2012-05-30 21:55:07 |
Message-ID: | 20120530215507.GD26894@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, May 30, 2012 at 11:51:23AM -0700, Jeff Janes wrote:
> On Wed, May 30, 2012 at 11:23 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> > On Wed, May 30, 2012 at 11:06:45AM -0700, Jeff Janes wrote:
> >> On Wed, May 30, 2012 at 10:57 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> >> > On Wed, May 30, 2012 at 10:38:10AM -0700, Jeff Janes wrote:
> >> >>
> >> >> Isn't that what the buffers_alloc from pg_stat_bgwriter is ?
> >> >
> >> > The issue is that once a buffer is removed from the free list, it is
> >> > never returned to the free list.
> >>
> >> A buffer doesn't need to be removed from the linked list in order for
> >> buffers_alloc to get incremented.
> >
> > Seems buffers_alloc is the number of calls to StrategyGetBuffer(), which
> > tells how many time we have requested a buffer. Not sure how that helps
> > measure buffer pressure.
>
> Once the linked list is empty, every request for a buffer to read a
> new page into must result in the eviction of the previous occupant
> from this conceptual freelist buffer (except perhaps for some race
> conditions). Isn't that what you wanted? Except that the
> buffers_alloc does not get incremented when the StrategyGetBuffer is
> satisfied by a ring strategy rather than the default strategy.
Well, the ideal case is that I could find out how often data that is
near to be discarded is actually needed, hence the "reclaimed" field
that is often important for kernel memory presssure reporting on older
operating systems. I will post an email soon about my theory of why
buffer pressure is an important thing to report to users.
> >> Conceptually, the freelist consists not only of the linked list, but
> >> also of all unpinned buffers with a usagecount of zero.
> >
> > True. I guess my problem is can't find out how many of those
> > zero-uage-count buffers are being reclaimed as needed.
>
> Do you need to figure this out specifically in the context of bulk
> strategies, or did you just pick a sequential scan because you thought
> it would be an easy test case? When I need to generate pressure on
> the buffer cache, I use pgbench -S.
I thought it would just be easy. I was susprised we were favoring
kernel reads over using more than 256k of shared buffers.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
From | Date | Subject | |
---|---|---|---|
Next Message | Erik Rijkers | 2012-05-30 22:00:46 | Re: FailedAssertion("!(PrivateRefCount[i] == 0)", File: "bufmgr.c", Line: 1741 |
Previous Message | Ants Aasma | 2012-05-30 21:42:45 | Early hint bit setting |