| Subject | Re: [firebird-support] Re: Performance tuning large FDB |
|---|---|
| Author | Helen Borrie |
| Post date | 2006-01-20T13:54:25Z |
At 02:19 PM 20/01/2006 +0100, you wrote:
cache. Its use is to progressively cache data and index pages that have
already been read, to reduce the number of disk I/Os.
to. It is a cache in RAM and the server does manage the cache, i.e. it
maintains it, requests more if necessary [or if possible], writes to it,
reads from it, switches out obsolete pages, et al. But it doesn't use the
page cache for anything but page caching.
There's a big difference in the way the page cache is used, too, depending
on whether you are using SS or Classic. And page cache should *always* be
budgeted for allocation from RAM: paging it to disk defeats its purpose.
The way the OS manages RAM *does* matter. If RAM is available, the server
will use it for storing the intermediate sets during sorting operations
(order by, group by) and (I think) for unions. This RAM is managed by the
OS and it's as likely to be paged to disk as any other RAM that is managed
by the OS. If virtual memory is insufficient for the sort operation, the
engine will store the entire intermediate output in disk files. You should
allocate space on disk for this, preferably on your fastest disks and NOT
on the same physical disk[s] where the OS is caching RAM.
You can bump up the maximum RAM available for sorts by reconfiguring the
SortMemBlockSize and SortMemUpperLimit parameters.
this by Ann Harrison in the second issue of the IBDeveloper magazine at
www.ibdeveloper.com ....
./heLen
>Thats good to know. Its just that I don't know what is more efficient,It's not a question of comparison. FB's cache is a dynamic page
>the Linux caches or FB's caches...
cache. Its use is to progressively cache data and index pages that have
already been read, to reduce the number of disk I/Os.
> > DB splitting increases complexity i think. buying an extra 8GB willPage caching is not "memory management", of the kind you are referring
> > be more cheap for you. ( so, OS can cached your DBfile fully)
>
>[...] it would be good to know who's better at managing a RAM
>cache: Linux or FB. I would say theoretically FB has the better cards
>because it knows more precisely what is going on. The OS can only look
>at disc blocks being accessed. The programmer can help FB if its own
>caching mechanisms aren't able to utilise the full 8- GB.
to. It is a cache in RAM and the server does manage the cache, i.e. it
maintains it, requests more if necessary [or if possible], writes to it,
reads from it, switches out obsolete pages, et al. But it doesn't use the
page cache for anything but page caching.
There's a big difference in the way the page cache is used, too, depending
on whether you are using SS or Classic. And page cache should *always* be
budgeted for allocation from RAM: paging it to disk defeats its purpose.
The way the OS manages RAM *does* matter. If RAM is available, the server
will use it for storing the intermediate sets during sorting operations
(order by, group by) and (I think) for unions. This RAM is managed by the
OS and it's as likely to be paged to disk as any other RAM that is managed
by the OS. If virtual memory is insufficient for the sort operation, the
engine will store the entire intermediate output in disk files. You should
allocate space on disk for this, preferably on your fastest disks and NOT
on the same physical disk[s] where the OS is caching RAM.
You can bump up the maximum RAM available for sorts by reconfiguring the
SortMemBlockSize and SortMemUpperLimit parameters.
>My luck has run out with 8GB. Server memory banks are full and availableYou can also reconfigure the Lock Manager memory. There's an article about
>budget has been all used. Should get me a long way though...
this by Ann Harrison in the second issue of the IBDeveloper magazine at
www.ibdeveloper.com ....
./heLen