Kjell,

> Den 2011-08-09 09:12 skrev Thomas Steinmaurer såhär:
>> Firebird uses RAM for different purposes
>>
>> - Caching pages
>> - Temporary data
>> - Lock table
>>
>> While configuring the page cache is well-known, Firebird provides
>> configuration parameters for caching temporary data used in sort/merge
>> operations as well. To be found in firebird.conf. But, these settings
>> are in Classic/SuperClassic per connection, so often hard to deal with,
>> especially for not getting near to a swap to disk scenario.
>>
>> So, basically I like to have a RAM disk for temporary data, which usage
>> can be configured per Firebird instance in firebird.conf.
>
> Do you mean that it's really a waste of RAM to put the entire DB there
> for fast searches, and that it's probably better to configure a large
> page cashe and put the temp data on a RAM disk?

I would rather like to see my databases on a fast persistent storage and
not RAM and tune RAM usage via page caching, temp data caching etc ...

> I guess that would work well, assuming that
>
> 1. it is not a problem that the searches are slow until all relevant
> pages have been cached,
>
> 2. writes do not have to be fast,
>
> 3. the page cache can be made large enough for all the relevant pages to
> fit.
>
> For us, point 1 is not OK. We have to be fast even after a fresh reboot.

Hmm, you could run a SELECT COUNT(*) on all or the most important tables
at startup, in the night etc ... which basically loads pages from disk
into memory/cache, if there is enough page cache available.

> Point 2 and 3 would be OK I think, especially since our classic mode
> server is really only accessed by one or a few connections (currently a
> single one).

The problem with one connection is that a single connection (one process
in CS) still can only use one CPU/core, so you are basically stuck with
the max. processing power of a single CPU/core.

Even if you have pages etc. in memory, this stuff needs to be processed
by the CPU as well. As Firebird does not cache particular result sets in
memory but pages, Firebird needs to process pages (even in memory) to
execute a statement each time the statement is executed.

In respect to the page cache in Classic. You know its the page buffers
value per connection. Configuration can get hard with a growing number
of connections, where possibly only one connection need a larger page
cache. With Classic, there is also a way to define a temporary page
buffers value at connect time, valid only in context of the connection.
Pretty useful, but your access components need to support that, I think.
E.g. isql has a CACHE clause for the CONNECT statement. I tend to use a
higher temporary cache e.g. when creating indices on largish tables,
because the index creation task loves more memory.



--
With regards,

Thomas Steinmaurer
Upscene Productions
http://www.upscene.com
http://blog.upscene.com/thomas/

Download LogManager Series, FB TraceManager today!
Continuous Database Monitoring Solutions supporting
Firebird, InterBase, Advantage Database, MS SQL Server
and NexusDB!