Thread: shared_buffers vs Linux file cache

> From: Huan Ruan <huan.ruan.it@gmail.com>
>To: pgsql-performance@postgresql.org
>Sent: Thursday, 15 January 2015, 11:30
>Subject: [PERFORM] shared_buffers vs Linux file cache
>
>
>
>Hi All
>
>
>I thought 'shared_buffers' sets how much memory that is dedicated to PostgreSQL to use for caching data, therefore not
availableto other applications. 
>
>
>However, as shown in the following screenshots, The server (CentOS 6.6 64bit) has 64GB of RAM, and 'shared_buffer' is
setto 32GB, but the free+buffer+cache is 60GB.  
>
>
>Shouldn't the maximum value for free+buffer+cache be 32GB ( 64 - 32)?
>Is 'shared_buffers' pre allocated to Postgres, and Postgres only?

>

I've not looked at the images, but I think you're getting PostgreSQL shared_buffers and the OS buffercache mixed up;
theyare not the same. 

PostgreSQL shared_buffers is specific to postgres, whereas the OS buffercache will just use free memory to cache data
pagesfrom disk, and this is what you're seeing. 

Some reading for you:
http://www.tldp.org/LDP/sag/html/buffer-cache.html

Glyn

Jeff Janes <jeff.janes@gmail.com> writes:
> On Thu, Jan 15, 2015 at 3:30 AM, Huan Ruan <huan.ruan.it@gmail.com> wrote:
>> I thought 'shared_buffers' sets how much memory that is dedicated to
>> PostgreSQL to use for caching data, therefore not available to other
>> applications.

> While PostgreSQL has reserves the right to use 32GB, as long as PostgreSQL
> has not actually dirtied that RAM yet, then the kernel is free to keep
> using it to cache files.

Another thing to keep in mind is that, even if Postgres *has* used the
RAM, the kernel might decide to swap parts of it out if it's not being
used heavily.  This is pretty disastrous from a performance standpoint,
so it's advisable to not make shared_buffers very much larger than what
your application will keep "hot".

Ideally we'd lock the shared buffer arena into RAM to prevent that,
but such facilities are often unavailable or restricted to root.

            regards, tom lane