> We have been doing something similar to what you are trying without having to take the risk of running the DB in Ram, let me explain:
>
> In FB 2.1 64 bits (for Windows) we have been running the superserver version, with a very large DB. We configured the FB server to run about 2 GB of cache in ram, and set many other FB config variables to enhance performance. FB 2.1 64 bits has a limit of how much cache it can hold in ram, I think that is 2.5GB if I remember correctly. The limitation does not make any sense as the OS is 64 Bits and should be able to handle much more (from memory 32 bits OS can handle 2 potency of 32, been 4 GB, and 64 Bit OS would be 2 potency of 64, been a number I cannot even imagine). Any-ways, running the DB in ram is very risky, and you can avoid it by just placing a big cache on the FB configuration, and have a Server with 64 GB ram, and configure the RAID controller to allocate 100% priority to read cache. If you have a good RAID configuration, say 8 HDD on Raid 6, the reading speed would be 6 x HDD speed, and today you can buy SAS HDDs with very fast reading capabilities. I also t

hink you may be able to have the DB file actually cached by the OS (for reading purposes) instead of having FB doing so, then why risk it?

>
> I am not sure if FB 2.1 64 for Linux has the same limitation in terms of the cache, it may be worth checking it,

The maximum number of page buffers for Firebird 64-bit has been
increased in version 2.5 to (2^31 - 1).



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