Re: DB page cache/query performance - Mailing list pgsql-general

From Greg Smith
Subject Re: DB page cache/query performance
Date
Msg-id Pine.GSO.4.64.0805141859490.8027@westnet.com
Whole thread Raw
In response to DB page cache/query performance  ("George Pavlov" <gpavlov@mynewplace.com>)
Responses Re: DB page cache/query performance  (Decibel! <decibel@decibel.org>)
List pgsql-general
On Wed, 14 May 2008, George Pavlov wrote:

> Is there a way to tell whether a query is satisfied from memory cache or
> from disk.

No.  You can look at the hit rate statistics for the tables and indexes
referenced and see how they change before and after the query, but this
just tells you about whether things were found in the PostgreSQL buffer
cache.  The database has no idea how much additional caching is going on
at the OS level below it.  Most people end up running "vmstat 1" and/or
"iostat 1" to see what is actually moving around on disk.  If you install
dstat that's a handy way to combine what would normally be split between
those two.

> Can I calculate exactly (based on PG config and OS parameters) the
> amount of memory available for DB page caches?

You can estimate it based on shared_buffers and the output from free.
Example:

$ free
              total       used       free     shared    buffers     cached
Mem:       2074940    1161764     913176          0     205416     530116
-/+ buffers/cache:     426232    1648708
Swap:      1992020          0    1992020

The upper limit for how much the OS might be caching for you is the
1648708 in this example.  Add that to the size of shared_buffers you
allocated, and you have a decent estimate for the total memory available,
which is also what to set effective_cache_size to.

> Also, how long should pages stay in the cache? (Assuming I have way more
> memory than the total size of all the tables/indexes.) Is there any
> time-based expiration (in addition to LRU-based, which in my case should
> never be resorted to)?

Forever, at least as far as the PostgreSQL one is concerned.  They only
get evicted when a new buffer needs to be allocated and there's none
available.  It's not quite a LRU mechanism either.  If you visit
http://www.westnet.com/~gsmith/content/postgresql/ there's a presentation
called "Inside the PostgreSQL Buffer Cache" that goes over how that part
works.  You'd probably find a look inside your system using pg_buffercache
informative.  Some of the sample queries I give only work on 8.3, but the
"Buffer contents summary, with percentages" one should be OK on 8.1.

Linux doesn't do any time-based expiration that I'm available of either,
it just uses a customized second-chance LRU I think.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD

pgsql-general by date:

Previous
From: "George Pavlov"
Date:
Subject: DB page cache/query performance
Next
From: Martin Marques
Date:
Subject: bug on ALTER TABLE