Re: 2nd Level Buffer Cache

Поиск
Список
Период
Сортировка
От Jim Nasby
Тема Re: 2nd Level Buffer Cache
Дата
Msg-id 267AE6DC-6597-4845-B84C-FDC1CDD7103C@nasby.net
обсуждение исходный текст
Ответ на Re: 2nd Level Buffer Cache  (Gurjeet Singh <singh.gurjeet@gmail.com>)
Ответы Re: 2nd Level Buffer Cache  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: psql \dt and table size
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: psql \dt and table size