Subject Re: 1.5.2 memory leak - fixed
Author unclejung
Success!

I was able to trace the leak to a few UDF calls in a insert trigger on
one of the databases. It was a no (low) maintainance database that we
paid very little attention to but did receive a high volume of
incoming data. Our server memnory footprint now stabilizes after a
week as expected.

Thank you for your help, especially Ann for a concise explanation of
memory usage by Firebird. While the UDF memory leak cause is pretty
obvious, I have overlooked it several times in this case. It is only
when I sat down and scrutinized all the possible suspects that I
realize that nothing else made sense, hence another look.

- Jung

--- In firebird-support@yahoogroups.com, "unclejung" <jungv@a...> wrote:
>
> This is exactly the information I need to figure out what's happening.
> Thank you Ann!
>
> - Jung
>
> --- In firebird-support@yahoogroups.com, "Ann W. Harrison"
> <aharrison@i...> wrote:
> > unclejung wrote:
> > >
> > >
> > > If all the connections are closed, and the database has no active
> > > transaction, shouldn't the server release all the memory except for
> > > the cache? Or is there something else I am missing. I am trying to
> > > find a way to narrow down the causes.
> > >
> >
> > The server handles three types of memory.
> >
> > The page cache is allocated as necessary, up to the amount set by the
> > various configurations - per database, per server, per configuration
> > file - and never released.
> >
> > Sort memory is allocated as required up to a configuration setting
and
> > released when the sort completes.
> >
> > Other memory is allocated in pools to describe such things as system
> > metadata, compiled requests, transaction state, undo logs, etc. Some
> > pools belong to the system - metadata is one - some belong to
> > connections - compiled requests for one - some belong to
transactions,
> > and some belong to active requests. The server will release pools
> > related to closed connections, transactions, and requests, but
releases
> > them to its internal free space for recombination and reuse.
> >
> > What that should mean is that the server's memory use will increase
> over
> > time, up to a limit that represents the amount of memory needed to
> > support the highest load yet encountered, then stop growing until a
> > higher load is encountered.
> >
> >
> > Regards,
> >
> >
> > Ann