Subject | Re: [firebird-support] FB GBK and CPU Usage |
---|---|
Author | Thomas Steinmaurer |
Post date | 2008-10-13T10:54:47Z |
Hello Andrew,
somewhere producing a gap between OAT and NT of ~1.5 mio. A wonder that
the server is still alive.
To identify a long-running transaction with Firebird prior v2.1 can be
tricky, that said, you need to have your hands on the client application
source and know what it does regarding transaction management.
If you are in a heterogenous environment regarding access components
(e.g. BDE, IBX, IBO, ...) it even get worse.
The reason for slow DB performance during a backup with gbak usually is
due to garbage collection in the source database. This can be omitted
with the -g switch of gbak.
Anyway, you need to fix the transaction management in your client
applications, otherwise it's just a matter of time to get into
performance troubles again.
Identifying long-running transactions would be easy with Firebird 2.1
due to the monitoring tables. So, if you are able to upgrade your system
in a test environment to 2.1 this might be useful. Although, upgrading
the client application to 2.1 might result in upgrading the access
components as well ... You have to read the compatibility issues section
in the Firebird release notes.
You also could try our Firebird Transaction Statistic Logger utility to
e.g. spot a timestamp, where e.g. the gap between the transaction
counters drift away, although it won't tell you which transaction is
long-running.
http://blog.upscene.com/thomas/index.php?d=02&m=10&y=08&category=12
--
Best Regards,
Thomas Steinmaurer
LogManager Series - Logging/Auditing Suites supporting
InterBase, Firebird, Advantage Database, MS SQL Server and
NexusDB V2
Upscene Productions
http://www.upscene.com
My blog:
http://blog.upscene.com/thomas/
> We are getting really slow DB performance during backups, we're a 24/7Your header statistics shows that you have a long-running transaction
> company and so cant run them during a down period.
>
>
>
> Gbak runs about 6-10% and FBServer runs a good 50% (dual core box so
> flat out on one core)
>
> After gbak has finished the fbserver is still running around 50%
>
> Is this normal?
>
>
>
> It's a windows 2003 box with fb 1.5
>
>
>
> I think the below isn't right, but im a total 'noob' when it comes to
> databases
>
>
>
> Any help would be greatly appreciated
somewhere producing a gap between OAT and NT of ~1.5 mio. A wonder that
the server is still alive.
To identify a long-running transaction with Firebird prior v2.1 can be
tricky, that said, you need to have your hands on the client application
source and know what it does regarding transaction management.
If you are in a heterogenous environment regarding access components
(e.g. BDE, IBX, IBO, ...) it even get worse.
The reason for slow DB performance during a backup with gbak usually is
due to garbage collection in the source database. This can be omitted
with the -g switch of gbak.
Anyway, you need to fix the transaction management in your client
applications, otherwise it's just a matter of time to get into
performance troubles again.
Identifying long-running transactions would be easy with Firebird 2.1
due to the monitoring tables. So, if you are able to upgrade your system
in a test environment to 2.1 this might be useful. Although, upgrading
the client application to 2.1 might result in upgrading the access
components as well ... You have to read the compatibility issues section
in the Firebird release notes.
You also could try our Firebird Transaction Statistic Logger utility to
e.g. spot a timestamp, where e.g. the gap between the transaction
counters drift away, although it won't tell you which transaction is
long-running.
http://blog.upscene.com/thomas/index.php?d=02&m=10&y=08&category=12
--
Best Regards,
Thomas Steinmaurer
LogManager Series - Logging/Auditing Suites supporting
InterBase, Firebird, Advantage Database, MS SQL Server and
NexusDB V2
Upscene Productions
http://www.upscene.com
My blog:
http://blog.upscene.com/thomas/