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
your
> typical executions and memory growth issue.
>
> Roman
>