At 09:36 AM 10/19/2000 -0700, Dan Palley wrote:

>I found this item in the Interbase knowledgebase and I'm somewhat concerened
>about it's implications:
>
>"When InterBase allocates memory to perform operations, it does not ever
>return this memory to the operating system. This memory is returned to
>InterBase's internal memory free list, but it is never returned to the
>operating system for other processes to use. Thus the memory is
>not freed until the InterBase service is stopped or the machine is
>rebooted."
>
>What type of operations in Interbase would cause this to happen? Was this
>addressed at all in Interbase 6?

InterBase manages a pool (actually several pools and a lagoon) of
memory from which it allocates various blocks that describe metadata,
compilation elements, execution trees, etc. It's memory management
is quite good - it won't, for example, leave little dribs and drabs
around, too small to use. When a request goes from compilation to
execution, the compilation specific memory is released to the pool.
When it completes and the prepared query is released, all of the
memory associated with the query is returned to the pool.

Only if there is not enough memory available in the pool will memory
be allocated from the operating system. Generally the amount of
memory used rises in proportion with the number of users. So, if
your server has 2 users on weekends (me and you, no doubt) and 50
during the week, it will hold enough memory to serve all fifty, but
will go from 2 to back 50 without allocating more.

In general, you will find that InterBase doesn't use a lot of memory,
unless you request a ridiculous number of pages for the cache. One
of the major tasks in moving to the SuperServer architecture was
locating and stopping all memory leaks. This is a non-problem (I
think).


Regards,

Ann