Re: 2nd Level Buffer Cache - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: 2nd Level Buffer Cache
Date
Msg-id 267AE6DC-6597-4845-B84C-FDC1CDD7103C@nasby.net
Whole thread Raw
In response to Re: 2nd Level Buffer Cache  (Gurjeet Singh <singh.gurjeet@gmail.com>)
Responses Re: 2nd Level Buffer Cache
List pgsql-hackers
On Mar 25, 2011, at 10:07 AM, Gurjeet Singh wrote:
> On Tue, Mar 22, 2011 at 3:53 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Tue, Mar 22, 2011 at 11:24 AM, Jeff Janes <jeff.janes@gmail.com> wrote:
> > On Fri, Mar 18, 2011 at 9:19 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> >> On Fri, Mar 18, 2011 at 11:14 AM, Kevin Grittner
> >> <Kevin.Grittner@wicourts.gov> wrote:
> >>> Maybe the thing to focus on first is the oft-discussed "benchmark
> >>> farm" (similar to the "build farm"), with a good mix of loads, so
> >>> that the impact of changes can be better tracked for multiple
> >>> workloads on a variety of platforms and configurations.  Without
> >>> something like that it is very hard to justify the added complexity
> >>> of an idea like this in terms of the performance benefit gained.
> >>
> >> A related area that could use some looking at is why performance tops
> >> out at shared_buffers ~8GB and starts to fall thereafter.
> >
> > Under what circumstances does this happen?  Can a simple pgbench -S
> > with a large scaling factor elicit this behavior?
>
> To be honest, I'm mostly just reporting what I've heard Greg Smith say
> on this topic.   I don't have any machine with that kind of RAM.
>
> I can sponsor a few hours (say 10) of one High-memory on-demand Quadruple Extra Large instance (26 EC2 Compute Units
(8virtual cores with 3.25 EC2 Compute Units each), 1690 GB of local instance storage, 64-bit platform). That's the
largestmemory AWS has. 

Related to that... after talking to Greg Smith at PGEast last night, he felt it would be very valuable just to profile
howmuch time is being spent waiting/holding the freelist lock in a real environment. I'm going to see if we can do that
onone of our slave databases. 
--
Jim C. Nasby, Database Architect                   jim@nasby.net
512.569.9461 (cell)                         http://jim.nasby.net




pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: psql \dt and table size
Next
From: Pavel Stehule
Date:
Subject: Re: psql \dt and table size