Subject | Re: [firebird-support] Memory tune-up on Firebird 1.5 Embedded |
---|---|
Author | Svein Erling Tysvaer |
Post date | 2007-01-09T08:02:03Z |
Hi Val!
The one thing that doesn't make sense (at least not until you tell us
about some very unusual requirements), is to load the entire DB. That's
the desktop database approach, but Firebird is a client/server database
and you should work with datasets only containing records and fields
that you're currently working on (even when using the embedded server).
Hence, I'd say the main problem is your design, and that playing with
parametres at best can be considered making the consequences of a bad
decision less visible.
Set
val_melamed wrote:
The one thing that doesn't make sense (at least not until you tell us
about some very unusual requirements), is to load the entire DB. That's
the desktop database approach, but Firebird is a client/server database
and you should work with datasets only containing records and fields
that you're currently working on (even when using the embedded server).
Hence, I'd say the main problem is your design, and that playing with
parametres at best can be considered making the consequences of a bad
decision less visible.
Set
val_melamed wrote:
> Hello,
>
> We have a .NET desktop application which uses the Firebird 1.5
> embedded server. Generally the app loads the entire DB (typically 20-
> 50MB FDB files) in memory (in a .Net DataSet), displays it to the
> user and after that only when the user changes or adds something we
> save the change to the DB. In other words, the DB engine initially
> does a lot of reading, after that it does some writing via INSERT or
> UPDATE and almost no SELECT-s.
>
> In order to minimize the memory usage I played with some parameters
> in firebird.conf. Here are some numbers that show pretty good
> optimization in terms of memory usage:
>
> DefaultDbCachePages = 256
> SortMemBlockSize = 524288
> SortMemUpperLimit = 4194304
>
> What is your opinion? Do these parameters and numbers make sense with
> regards to other DB performance related criteria? Can we go even
> lower on some of these parameters? Are there other parameters which
> we could play with?
>
> A very important question for us is what if the DB is on a flash
> drive? What can we do to improve the performance there: not only in
> terms of memory usage but also I/O performance.
>
> Looking forward to your replies.
>
> Thank you
> Val Melamed