Skip site navigation (1) Skip section navigation (2)

Re: 2nd Level Buffer Cache

From: Jim Nasby <jim(at)nasby(dot)net>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, rsmogura <rsmogura(at)softperience(dot)eu>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: 2nd Level Buffer Cache
Date: 2011-03-18 18:15:10
Message-ID: (view raw, whole thread or download thread mbox)
Lists: 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(dot)Grittner(at)wicourts(dot)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.


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

In response to


pgsql-hackers by date

Next:From: Dan PortsDate: 2011-03-18 18:18:32
Subject: Re: SSI bug?
Previous:From: Josh BerkusDate: 2011-03-18 18:02:51
Subject: Re: Japanese developers?

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group