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