Re: Is there a way to specify size of cache and how much memory fb can use?
- Well I assume the db uses a lot of stack memory by traversing indices
in the btree, and many other fb operational functions - but maybe 300
MB isn't reasonable. It's just that I can't control how fb uses
memory doing these types of things. I wonder if I can...
--- In Firebird-Java@yahoogroups.com, Roman Rokytskyy <roman@...> wrote:
> > When I run the application I expect it not to use more than 100 MB.
> > But instead, it's using closer to 400MB. My app shouldn't use that
> > much memory and I'm wondering if there are other things to do to
> > control firebird's memory usage.
> > Anyone have any thoughts?
> Just talked to core developers. Two possible issues:
> a) you have overriden the page cache in the database. In this case the
> default one will be ignored. Unlikely, but you can check it anyway (use
> either FBStatisticsManager or gstat -h)
> b) the undo-log is growing. The undo log contains information about the
> record versions that would allow to rollback to the relevant savepoint.
> AFAIK, you cannot specify the upper bound for the memory used by the
> undo log, however you get it under control in your application avoiding
> complex statements, especially in stored procedures.
> The best would be if you create a reproducable test case that shows
> typical executions and memory growth issue.
> Well I assume the db uses a lot of stack memory by traversing indicesIt depends on number of the connections you have. Prepare, please, a
> in the btree, and many other fb operational functions - but maybe 300
> MB isn't reasonable. It's just that I can't control how fb uses
> memory doing these types of things. I wonder if I can...
test case and I can check the allocations in debugger...
But you're right - you don't have direct control over this. If you would
have hard limits there, some of your connections would fail with "Out of
So the real way is to find out how many memory is used by one connection
during the typical usage and then plan your parallel connections using
Your goal is to make the incoming requests to your application server
(Tomcat, for example) to stall in the incoming queue - this is the
pattern to which most browsers and applications are used to. This is
done by tuning the number of worker threads in the server - it should be
equal to your desired memory footprint.
Other patters might cause different timeouts in different places (e.g.
when getting connection from the pool), which is harder to cope with.