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

>If this is unavoidable, is it possible to have the service close to
>be restarted by guardian rather than remain open but refuse
>connections?

Throw the baby out with the bathwater? If you shut down the server,
you abort all uncommitted work in 30 databases. You could build a
middle tier that queues connection requests.

>Also, which settings should I be changing. [..] I should
>mention that all settings in the conf file are default.

I doubt that you could go lower with page cache. You could look at
reducing the amount of RAM used by sorts. Try to reduce (or
eliminate) application workflows that eat too much memory, e.g. don't
use ReadCommitted in read-write transactions, don't keep SELECTS
alive in read-write transactions for long periods, etc.

30 is a lot of databases for one Superserver if most are doing writes
most of the time. Add another server? (A 2 Gb Linux box with
nothing else to do?) Or throw more RAM at the machine and run
another Superserver process on it, or go to Classic?

./heLen