Subject | Re: [firebird-support] Classic Server User Limit |
---|---|
Author | Steve Wiser |
Post date | 2007-07-12T12:58:14Z |
look in /etc/xinetd.d/firebird and make sure your instances is set to
UNLIMITED or whatever value you want... Also look in /etc/xinetd.conf
and set the instances value there as well (we also up the cps setting
for each server).
-steve
dr_john_mp wrote:
UNLIMITED or whatever value you want... Also look in /etc/xinetd.conf
and set the instances value there as well (we also up the cps setting
for each server).
-steve
dr_john_mp 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.
>
> We obviously need to look at some of the parameters of the lock
> manager and cache sizes - 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.
>
> 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. 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. 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.
>
> >
>
>