Subject RE: [firebird-support] FB GBK and CPU Usage
Author Alan McDonald
> Hi All
> We are getting really slow DB performance during backups, we're a 24/7
> 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
> Cheers
> Andrew
> D:\Program Files\Firebird_1_5\bin>gstat -h e:\data\cabs.fdb
> Database "e:\data\cabs.fdb"
> Database header page information:
> Flags 0
> Checksum 12345
> Generation 9959021
> Page size 4096
> ODS version 10.1
> Oldest transaction 8479679
> Oldest active 8479680
> Oldest snapshot 8378442
> Next transaction 9959010
> Bumped transaction 1
> Sequence number 0
> Next attachment ID 0
> Implementation ID 16
> Shadow count 0
> Page buffers 0
> Next header page 0
> Database dialect 3
> Creation date Jan 18, 2008 2:31:22
> Attributes force write
> Variable header data:
> Sweep interval: 20000
> *END*
>

These are the stats from one of my production DBs. Much more recently
restored after some log maintenance work so about 1 million less
transactions overall, but about 21K transactions per day compared with your
36K transactions per day.
But the gap between my oldest active and next transaction is 4
the gap for you is approx 1.5 million.
(mine is also 24/7 20-30 users including replaction processes)
I'd say that underscores your problem.
A lot of transactions are being left uncommitted or unrolled back. This
certainly makes for a DB which slowly grinds to a snails pace. It's trying
to manage all those back versions for all those transactions which it thinks
are still active.
And the garbage collection job gets very difficult and time consuming also.
Backups will be faster if you use -g switch which stops garbage collection
taking place. But this is not a good long term solution for you IMO.
You need to sort out why those transactions aren't moving ahead.
Alan

Database header page information:
Flags 0
Checksum 12345
Generation 823167
Page size 8192
ODS version 10.1
Oldest transaction 799364
Oldest active 817236
Oldest snapshot 817236
Next transaction 817240
Bumped transaction 1
Sequence number 0
Next attachment ID 0
Implementation ID 16
Shadow count 0
Page buffers 0
Next header page 0
Database dialect 3
Creation date Sep 5, 2008 18:03:54
Attributes force write