On Wed, Jun 8, 2011 at 1:29 AM, Maya Opperman <maya@...> wrote:

> These page buffers confuse me greatly, and it seems the correct calculation is a tricky process.
>
> QUESTION: how do you know if you have it wrong? ie. too high or too low? What happens exactly?

In case anyone missed the obvious, page buffers is the parameter that
controls the size of Firebird's I/O cache. The purpose of an I/O
cache is to minimize the number of page reads. If the cache is too
small, pages are read, released to make space for more urgently needed
pages, and then read again. If the cache is bigger than the
available physical memory, it page faults, which means it's not saving
I/O at all, just moving it from the Firebird process to the operating
system.

In SuperServer, there's only one cache, so the number you choose for
page buffers times the page size is the amount of RAM that Firebird
will use to minimize I/O. In Classic, there's one cache per
connection, so the the memory used is page buffers times page size
times connections. Obviously, going from 32-bits to 64-bits greatly
increases the amount of memory that can be addressed, so if you're
running classic with lots of users, you should be running 64 bit.

How do you know if the page buffer parameter is too small? Use the MON$IO_STATs
table to get the database wide I/O levels. The best page buffer
value is the one that minimizes the ratio of reads to fetches. Don't
worry too much about writes vs marks, because that's affected by
commits. A read goes to disk, a fetch is a request for a page that is
already in cache.

So, no, it's not a mystic science. Don't allocate more cache than you
have addressable memory, and use the available I/O statistics to
measure the effectiveness of the cache.

There is a mystical discussion of the interaction between Firebird's
page cache and the operating system file cache, since they're both
doing the same thing and Firebird has more information about which
pages to cache, but that's OS type and version specific.

Good luck,


Ann