Subject Re: [firebird-support] 1.8Gb database performance issues
Author Svein Erling Tysvaer
I think the most common causes for performance degradation are poor
transaction handling and suboptimal queries. Neither of these can be
fixed (though maybe they can be eased a little bit, others will know
more about this) through configuration settings.

So: What happens if you take a backup/restore of the database? Is the
restored database slow when accessing it through your application?

1) If yes, then I suspect suboptimal queries. Have you added or removed
any indexes (making them inactive counts as removing) lately or changed
some queries? Any particular query that is slow? Have your database
grown substantially so that queries now have to do considerably more work?

2) If no, then I suspect poor transaction handling. What is your
statistics, is there a big gap between oldest interesting/active and
next transaction?

Please report back your findings and - if the problem remains - whether
you are using SuperServer or Classic.

I take it that you've not changed server or operating system lately.


mailgroupza wrote:
> Hi
> We have an application which has worked well for a few years now but=20
> we are now seeing a huge degradation in performance.
> Server: Dedicated to firebird Dell 2850 8GB Ram, 2 x 3.6Ghz xeon=20
> processors, Raid 5
> OS: Mandrake linex 2.6.11
> Database: 1.8 Gb (single db)
> Firebird: Ver 1.5
> The current settings which I think are relevant are as follows:
> #SortMemBlockSize =3D 1048576
> #SortMemUpperLimit =3D 67108864
> #CpuAffinityMask =3D 1
> DefaultDbCachePages =3D 8192