At 07:55 PM 12/07/2007, you wrote:

>We have just upgraded from 2.0.0 to 2.0.1 and took the opportunity to
>switch to Classic Server as we have 30+ users most of whom will run
>more than one database application.
>
>We have been running 2.0.0 classic on our development server for some
>time so were reasonably confident - both the development and live
>servers run Linux
>
>As the users built up we rapidly got into a situation where
>connections were failing, with approx 28 active instances of the
>program.

It sounds suspiciously like your xinetd.conf is configured to limit
instances to 30, which seems to be the default in most Linux distros
I've been using. "Approx 28" sounds like 28 active plus a couple in
the process of completing transactions after detach requests. If
you don't have instances explicitly configured to a higher number
than your max. expected concurrent connections inside your
xinetd.d/firebird file then the daemon will hobble it at the setting
in xinetd.conf.

>We obviously need to look at some of the parameters of the lock
>manager and cache sizes -

Cache size might be an issue, if you retained your firebird.conf from
your Superserver installation. Classic instances use a private cache
per connection, not a globally shared cache like SS. But you'd want
to check your settings and memory usage first, to establish whether
you actually have a premise for altering the cache setting. Lock
Manager should be fine with the default setting but, if you have the
RAM, you could tweak it up to a higher number of hash slots (needs a
prime number).

>to avoid downtime we have installed 2.0.1
>Superserver so have a bit of time to sort things out.
>
>However we were left with some questions
>
>Is there a way to identify the cause of the limitation - we didn't
>appear to get any errors in the Firebird log as I would have expected.
>
>In Classic how do you forcefully stop and restart the server, without
>individually killing every instance. Asking every user to log out
>isn't always practical, and they don't always respond.

You don't "forcefully stop and restart the server" in Classic. There
is no "Firebird server" process running like the Superserver
process. It's just the xinetd daemon listening for connection
requests for its various "customers", including Firebird. When it
gets a request, it starts an instance of fb_inet_server for the
client. To end the instance, the client just detaches. If something
untoward happened between the client and its process, you kill the
offending process. But, even if you don't do that, it will kill
itself eventually, once it knows that the client has disappeared (by
default, that will take from 2 hours from when the process decides
the client has gone).

>How do you identify the number and names of current active users.
>Firebird creates a new instance for every connection, but with itself
>as the user.

Here you are not talking about database users, but Linux users. In
terms of Firebird users, a Classic process knows only about the user
that is connected to it.

>Programs like IBExpert will list/manage allowable users
>but in Classic only show itself as an active user (ie it only sees
>users in its own instance), as does a Delphi program using
>TIBSatisticalService.

Superserver is a process in its own right, that creates threads for
clients connecting to it. Therefore, it knows about all of the
clients that are connected to it.

>Most of our own applications write a status
>report to a 'RUNNING' table (eg with their oldest current transaction)
>but that doesn't track 'standard' applications.

It sounds unreliable, anyway. How would you deal with clients that
disappeared for some reason?

./heLen