Subject | Re: [firebird-support] Re: FB database in RAM - Email found in subject |
---|---|
Author | Thomas Steinmaurer |
Post date | 2011-08-09T08:13:55Z |
>>> Den 2011-08-09 09:12 skrev Thomas Steinmaurer såhär:With Classic, the cache then still is local to the connection. But if
>>> 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.
you have a three-tier setup, you might benefit from that.
>>> Point 2 and 3 would be OK I think, especially since our classic modeDepends on how CPU-intensive your connections are.
>>> 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.
>> In respect to the page cache in Classic. You know its the page buffersFor example, in one of my DWH environment, the database connection from
>> 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...
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!