At 02:31 AM 18/02/2005 +0000, you wrote:

>I am running 1.5.2 on Windows 2000 SP3.
>
>One of our server leaks memory. I am not sure how to go about
>identifying what database/operation is the culprit. Shutting down all
>the databases from a tool like IBManager doesn't release the memory.
>The only way I have found to release memory is to shutdown the
>Firebird server service.
>
>The server would start out using about 200 MB, and about 3 days later
>it would use a total of 400 MB and the number would keep climbing
>until I restart the Interbase Server service.
>
>How would I go about narrowing down the causes of this memory leak?

Check first whether your applications are hard-committing
transactions. It's a fairly common error to write systems in Delphi or
other Borland products and use the default AutoCommit for all transactions
and Read Committed as the isolation level. AutoCommit uses Commit
Retaining, which keeps transaction contexts open indefinitely.

Apart from the problem that CommitRetaining prevents garbage collection,
for ReadCommitted transactions the transaction state bitmap (TSB) is
maintained actively in memory. Persistent CommitRetaining calls, with no
hard commits, will cause the bitmaps to build up forever.

Regular bulk inserts in transactions with AutoCommit active will add an
extra memory overhead as an Undo log is maintained in memory for such batch
inserts. Its cleanup is suppressed by CommitRetaining as well.

All this doesn't make CommitRetaining a sin. It was put there by Borland
to save on resources usage with its BDE components. BDE applications are
notoriously fragile in many more ways than just memory management. Even
using the non-BDE alternatives that are out there now, CommitRetaining has
its benefits -- but only as long as the developer is keenly aware of the
effects from ignoring hard commits.

Now - even if you're using some other interface, it's well possible that
the transaction defaults are unfriendly to good memory management and disk
hygiene. CommitRetaining might be an issue; connection pooling without
the correct cleanup will cause leaks; network faults or naughty users that
cause connections to crash can leave artifacts in server memory that will
not be cleaned up until a timeout period has elapsed (or not at all, if the
application interface is causing cleanup to be suppressed!)...and so on.

Page cache may be over-configured for the server's environment, e.g. the
superserver default was applied to a Classic server; or it may be
dominated by huge indexes or multiple large operations on blobs, et al., et al.

This phrase makes one ponder:

>keep climbing until I restart the Interbase Server service.

Are you really running Firebird 1.5.2?

./heLen