Hi

We had a similar problem when we upgraded from firebird CS 2 to 2.1 The problem was fixed by http://tracker.firebirdsql.org/browse/CORE-2591.

We are currently running a version of 2.1.2 with that fix and it has worked well for the last 6 months.

Bernard

--- In firebird-support@yahoogroups.com, Stefan Sinne <stefan@...> wrote:
>
> Today our customer ran again into the performance problem.
> This time I looked at the transaction ids.
>
> When the problem was reported to us, OIT = 3662, OAT = 3663, NEXT = 32704.
>
> Then, at midday, I connected myself to the database and told everbody to
> close their applications.
> I even killed any fb_inet_server process (that was not my own, of course).
> After this the situation was: OIT = 35128, OAT = 35129, NEXT = 35133
>
> Even though, the response time kept as bad as before.
>
> Then I disconnected myself (closed our application) and saw the last
> fb_inet_server as well as the fb_lock_mgr process disappear.
> Then I entered again, and everything was fine again ?!
>
> So in my opinion there must be any problem with the lock manager process.
>
> Is there any known issue in FB 2.1 about the lock manager?
> Is there anything else I could do to track down the problem?
>
> Thanks,
>
> Stefan
>
> Svein Erling Tysvær escribió:
> >
> >
> > >Today we got a call from one of our customers telling us that our
> > >application responds very slow to their input.
> > >I told them to close the application on all clients and after this made
> > >a proove with a select from
> > >MON$ATTACHMENTS, where I just found one line with the current connection.
> > >
> > >I made a select on this database, which needed 50 secs, and then
> > >executed the same select on a copy
> > >of the same database (which we make every night), which just needed 5
> > secs!
> > >
> > >I took a look at the running processes and found 11 fb_inet_server
> > >processes running.
> > >After killing all of theses processes, the select needed the same 5 secs
> > >in both databases.
> >
> > Do the database statistics say anything about transaction gap? (Next
> > transation, oldest transaction, oldest active transaction...) Are
> > there lots of updates/deletes in your system or mostly inserts and
> > selects?
> >
> > Set
> >
> >
> >
>