>>> Den 2011-08-09 09:12 skrev Thomas Steinmaurer såhär:
>>> 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.
>
> Might work, yes. Thanks for the idea.

With Classic, the cache then still is local to the connection. But if
you have a three-tier setup, you might benefit from that.

>>> 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.
>
> Good point. It's already on my to do list to investigate how to setup
> ECO to use multiple connections and ECO space pooling. With 8 cores I
> guess up to eight connections will be useful, but perhaps no more than that.

Depends on how CPU-intensive your connections are.

>> 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.
>
> Interesting, but may not be relevant in our case. I'll have to think
> about it. Not sure the FB ADO.Net provider supports it...

For example, in one of my DWH environment, the database connection from
the OLAP server to the database might benefit from a larger local page
cache, but we haven't investigated that, because the OLAP server does
caching on its own etc ...


--
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!