Subject Re: internal gds software consistency check (cannot start thread)
Author Adam
> 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 ?

Can't answer for Helen, but from what we experienced your assumption
is correct.

> What would happen if all connections were disconnected ?

New connections are refused with 10061 indefinately. This is why I
don't see blowing away the process as throwing away the baby with the
bathwater. When all connections are disconnected, there is no work to
abandon.

>
> 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.

From what I have gathered, the computation is not so simple. Of course
only the windows distro could use the winapi too, but ideally I would
(as I am sure everyone else would) prefer the connection to break that
camels back be denied.

> Maybe some parameter in firebird.conf to refuse new connections when
> free memory is below defined limit would be good addition.
>

I am prepared to accept that the first database server simply ran out
of memory. This would have happenned at 1.6GB (and it is sharing that
RAM with Windows etc, so it may have only had 1GB). This issue has now
been addressed. The second server is much newer and I imagine it would
have required the firebird process to exceed the 2GB limitation to run
out of addressable memory.

Overnight it had peaked at 200MB total VM + MEM, so I can not as yet
confirm this is the only possible cause. If I wasn't on leave next
week, I would have switched to classic to see whether it resolves the
issue, so we (or more correctly they) are just closely monitoring the
process.

Adam