At 16:19 9/10/2008, Julian wrote:

>Helen,
>
>I'm sorry if I wasn't clear enough. I'm not concerned with the
>executable size, or how much data the DBMS can maintain. I'm
>concerned with how much main memory the DBMS/database server requires
>while running - not including the cached data in main memory that's
>used speed up database operations.

The more the better: but allow ~2 Mb for each concurrently connected process (Classic) or thread (SS...this is inexact as SS will re-use idle threads so there is not a 1:1 correlation, necessarily). If it can, Firebird will use RAM for sort operations but will offload to disk if insufficient is available. Operations on the server can use a lot of memory: how much depends on what you are doing (How long is a piece of string?) But database servers love memory. A number of memory usage settings are configurable - study firebird.conf for the version you are intending to install.

>Helen, you said it'd be good to know what I'm doing to answer my
>questions. Well I have a single un-dedicated computer running many
>applications on it that will be collecting sensory data from devices
>connected to the motherboard. Because the DBMS will not be the only
>thing running on the computer, the DBMS must have a small memory
>footprint. I am hoping it won't use more than 200MB, or 500MB
>including some cache space.

On 32-bit systems no application can use more than 2 GB of memory. So, if there are hundreds of connections, the potential for fatality is higher for SS than for Classic. If Firebird is competing with a lot of other stuff that chomps memory then you shorten your options.

>Since I am not a database admin or
>expert, I don't know what typical database server cache sizes are, so
>I don't know how much extra main memory is required to get good
>performance.

The default page cache for Firebird is configurable. It represents the number of database pages held in cache (which, once you're up and running, will gradually reduce the level of disk i/o). It's important to know that SS shares cache across all connections while Classic maintains individual caches per connection. The "shipped" default is 2K pages for SS and 75 pages for Classic. Actual size is page_size of your database * this number.

Good performance depends on other things besides cache. In-memory sorts are a lot faster than disk-based - unless of course you are pushing RAM-based work out to memcache anyway. Good indexing and good query plans, not getting too abstruse with your querying, taking good care of garbage collection and, particularly, keeping transactions under tight control - all these contribute far more importantly to performance than how much resource is available on sunny days.

>So anyway, these devices push ~100KB messages to my
>application with the embedded database (maybe firebird) every 10-100
>milliseconds. It would probably be best to cache these in my
>application and do a batch insert into the database. I will not allow
>the database to automatically do this caching clients on the LAN will
>connect to this application (NOT the database server itself) in order
>to retrieve data. I am running a single dual-core with 2GB of memory.
> Yes, I know it's not much. A candidate DBMS must be able to store
>32GB of memory on my SSD.

Sorry, you've lost me here in your acronyms.

>
>
>Helen, I realize that the superserver and the classic are two
>different models more or less of the same database server. You said
>that the superserver creates threads for each connection and for
>database housecleaning operations. To me that sounds like the
>superserver WOULD be able to make use of a multi-core computer.

Sigh. Multiple processors - NO. It's the one thing that people love to hate about SS.

Dual-core single processor: *I* don't know, so wait for someone who does.

> And
>you said that the classic model creates a new PROCESS for each
>connection, which sounds like the less efficient model for a
>multi-core since threads are more lightweight than processes.

Sez who?

Cd you do us a favour - trim your posts and don't top-post? Ta.

^ heLen