Subject | Re: [firebird-support] Two complicated questions firebird 2.5 cs |
---|---|
Author | Ann Harrison |
Post date | 2011-09-21T16:01:32Z |
Olaf,
but I'm equally sure it's not five. And the normal failure mode when
there's a conflict (suggested by the IBExpert holding a transaction open) is
for the whole system to lock up with nothing using CPU at all. So...
What are you doing that's different from everyone who's using Classic 2.5 64
bit on 64 bit Windows? One starting place would be to attach a debugger to
the process that's using huge amounts of CPU and not finishing. Stop the
process and get a call stack. Not terribly useful, but better than what
we've got now. And of course, take the vital signs*. Get a list of the
header page information (gstat -h is one way). Get a lockprint (look in the
firebird/bin directory for a file with a name like fb_lock_print.exe. I
think it prints the lock table header with no switches, but -h should tell
you what to use) . If you've got a working connection from which you can
query the MON$ tables check the state of other activity.
Good luck,
Ann
* "vital signs". For those of you who have the fortune not to have
experienced an American hospital, "vital signs" are pulse, blood pressure,
and temperature. Regardless of what appears to be wrong, the first thing
that happens is that someone checks your vital signs. If you have the great
misfortune to become a resident of a hospital, someone will check your vital
signs every three hours, day and night. They may miss the alarm that says
your heart has stopped, but they won't miss it by more than three hours
because it will be time for vital signs.
[Non-text portions of this message have been removed]
> we are using firebird 2.5 classic server 64 bit on windows server 2008I'm sure there's a limit somewhere, varying with operating system resources,
> standard 64 bit.
>
>
> Some clients (max. 5) are connected to our database. All of them close some
> transactions. But we using ibexpert. Now if we have some tables opened in
> IBEXPERT, some other clients cannot connect to our database by starting!
> The
> specified one task of fbserver (we are using classic) takes a lot of cpu
> capacity and the new task never ends. At this moment, we are also cannot
> work with ibexpert. If we close the hanging one task and close ibexpert,
> the
> other clients can connect to the fdb.
>
>
>
> One of the additional test is an isql-script wich started a stored
> procedure. The script is started by the windows scheduler every 5 minutes.
> If ibexpert is open, it can be that the dos-command-prompt remains opened
> and will never closed.
>
>
>
> How can we solve that problem? I think there are no limits like the
> connections to firebird?
>
but I'm equally sure it's not five. And the normal failure mode when
there's a conflict (suggested by the IBExpert holding a transaction open) is
for the whole system to lock up with nothing using CPU at all. So...
What are you doing that's different from everyone who's using Classic 2.5 64
bit on 64 bit Windows? One starting place would be to attach a debugger to
the process that's using huge amounts of CPU and not finishing. Stop the
process and get a call stack. Not terribly useful, but better than what
we've got now. And of course, take the vital signs*. Get a list of the
header page information (gstat -h is one way). Get a lockprint (look in the
firebird/bin directory for a file with a name like fb_lock_print.exe. I
think it prints the lock table header with no switches, but -h should tell
you what to use) . If you've got a working connection from which you can
query the MON$ tables check the state of other activity.
Good luck,
Ann
* "vital signs". For those of you who have the fortune not to have
experienced an American hospital, "vital signs" are pulse, blood pressure,
and temperature. Regardless of what appears to be wrong, the first thing
that happens is that someone checks your vital signs. If you have the great
misfortune to become a resident of a hospital, someone will check your vital
signs every three hours, day and night. They may miss the alarm that says
your heart has stopped, but they won't miss it by more than three hours
because it will be time for vital signs.
[Non-text portions of this message have been removed]