Re: DB page cache/query performance

Поиск
Список
Период
Сортировка
От Greg Smith
Тема Re: DB page cache/query performance
Дата
Msg-id Pine.GSO.4.64.0805141859490.8027@westnet.com
обсуждение исходный текст
Ответ на DB page cache/query performance  ("George Pavlov" <gpavlov@mynewplace.com>)
Ответы Re: DB page cache/query performance
Список 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 по дате отправления:

Предыдущее
От: "George Pavlov"
Дата:
Сообщение: DB page cache/query performance
Следующее
От: Martin Marques
Дата:
Сообщение: bug on ALTER TABLE