Hello Bernard.

Thanks a lot. That sounds very much as if we ran into the same problem,
especially since the problem started to appear after upgrading from
2.0.x (I don't remember the x but it was definitely not 5).

Can you please give me some indications on how you created the fixed
version of FB 2.1.2?
Or is it save to already use 2.1.4, which I think I can download from
the snapshots page?
I already compiled myself the FB project, since on our test server we
use different versions in different folders, but I always started from
the source tarball of the latest release.

Or would you recommend to downgrade to any version below 2.0.5? In that
case I think I will have to backup the database with gbak of 2.0.x under
engine 2.1.x, right?

Stefan

bernard_cleary escribió:

>
> 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.
> <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
> <mailto:firebird-support%40yahoogroups.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
> > >
> > >
> > >
> >
>
>

--
Stefan Sinne

Smart Software Solutions, S.L.
Trv. de la Vidriera 29 - bajo
E-33405 Avilés

email stefan@...
phone +34 985 119 203
fax +34 985 129 013