Re: 2nd Level Buffer Cache

Поиск
Список
Период
Сортировка
От Jim Nasby
Тема Re: 2nd Level Buffer Cache
Дата
Msg-id 9B2A55FF-2238-482F-848D-F19131883743@nasby.net
обсуждение исходный текст
Ответ на Re: 2nd Level Buffer Cache  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: 2nd Level Buffer Cache  (Robert Haas <robertmhaas@gmail.com>)
Re: 2nd Level Buffer Cache  (Josh Berkus <josh@agliodbs.com>)
Список pgsql-hackers
On Mar 18, 2011, at 11:19 AM, Robert Haas wrote:
> On Fri, Mar 18, 2011 at 11:14 AM, Kevin Grittner
> <Kevin.Grittner@wicourts.gov> wrote:
> A related area that could use some looking at is why performance tops
> out at shared_buffers ~8GB and starts to fall thereafter.  InnoDB can
> apparently handle much larger buffer pools without a performance
> drop-off.  There are some advantages to our reliance on the OS buffer
> cache, to be sure, but as RAM continues to grow this might start to
> get annoying.  On a 4GB system you might have shared_buffers set to
> 25% of memory, but on a 64GB system it'll be a smaller percentage, and
> as memory capacities continue to clime it'll be smaller still.
> Unfortunately I don't have the hardware to investigate this, but it's
> worth thinking about, especially if we're thinking of doing things
> that add more caching.

+1

To take the opposite approach... has anyone looked at having the OS just manage all caching for us? Something like
MMAPedshared buffers? Even if we find the issue with large shared buffers, we still can't dedicate serious amounts of
memoryto them because of work_mem issues. Granted, that's something else on the TODO list, but it really seems like
we'rere-inventing the wheels that the OS has already created here... 
--
Jim C. Nasby, Database Architect                   jim@nasby.net
512.569.9461 (cell)                         http://jim.nasby.net




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Dan Ports
Дата:
Сообщение: Re: SSI bug?
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Sync Rep and shutdown Re: Sync Rep v19