Helen Borrie wrote:

> At 10:19 AM 2/03/2006, you wrote:
>> --- In firebird-support@yahoogroups.com, "Adam" <s3057043@...> wrote:
>>> Hello Group,
>>>
>>> I have just experienced the same issue again overnight but on a
>>> different physical server.
>>>
>>> Here is my original post from Monday:
>>> http://groups.yahoo.com/group/firebird-support/message/72737
>>>
>>> This server is configured in a similar way with Win2003 Server, a
>> bit
>>> more RAM and two CPUs are the main differences. The second server is
>>> running Firebird 1.5.2.4731 Superserver. We have been watching the
>>> thread count and have not observed it over 30, so I fail to believe
>>> that running out of threads is the reason for this message. No
>>> software upgrades have occurred in this time so I am a little
>> concerned.
>>> Any assistance would be greatly appreciated.
>>>
>> Also, is this of interest for me or is this cause IB specific?
>
> http://support.borland.com/entry.jspa?externalID=3803&categoryID=153
>
> No. It's exactly the same for Firebird Superserver. A 32-bit
> process is a 32-bit process. However, the cure for Firebird has
> another option - use Classic.
>
>> I know
>> there is a 2GB limit but I don't think I am near it at this stage on
>> these servers (and no reason why they would suddenly become near it
>> within a week of each other either).
>
> > There are 30 (relatively
> > small) databases hosted on that machine, each has the default 4K page
> > size, so by my math this is 8MB RAM, a long way from 2GB.
>
> There is one page cache maintained for each database. 30 * 8Mb =
> 240Mb. (And, note, if you have even one database in the mix that has
> a larger cache configured, then all databases will use that size of
> cache.) Then, each thread uses ~ 2 Mb. (total connections * 30 * 2)
> will give an approximate (probably low) assessment of memory being
> used for connections. Add the lock table, which is dynamic, and
> roughly proportionate to #databases * #users * #operations. Then,
> count in sort memory for each select using orderings/groupings and
> for undo logs for multiple inserts per transaction, TIP copies
> maintained for Read Committed transactions, et al. On top of all
> that comes memory-intensive ops - optimization, building bitmaps and
> streams for joins, etc...

Sorry if my assumption is bad.Do I properly suspect that restart
Firebird server is required in this case to make it accepting new
connections even if older connections would be disconnected ?
What would happen if all connections were disconnected ?

If Firebird memory usage is so fine computable - why server doesn't do
such computation and simply refuse connection when there are no
available memory (memory pool used by process be can obtained using
WinApi and the same for available memory,right?) instead of crashing on
thread creation which probably means that main thread became frozen.
Maybe some parameter in firebird.conf to refuse new connections when
free memory is below defined limit would be good addition.