Subject | Re: Speed issues |
---|---|
Author | shaq@comalex.com |
Post date | 2004-09-22T13:28:23Z |
We have some clients which are running slow sometimes but not all the
time. I was just checking the statistics and referencing Helens book.
I found that in one of the statistics there is a gap of 6000 between
OIT and OAT. This I am assuming is very bad.
Does this mean that transactions are left open? The solution is to
fix our client and find out where transactions are being left open?
How does one determine when to increase the page size?
-Shaq
--- In firebird-support@yahoogroups.com, Svein Erling Tysvær
<svein.erling.tysvaer@k...> wrote:
time. I was just checking the statistics and referencing Helens book.
I found that in one of the statistics there is a gap of 6000 between
OIT and OAT. This I am assuming is very bad.
Does this mean that transactions are left open? The solution is to
fix our client and find out where transactions are being left open?
How does one determine when to increase the page size?
-Shaq
--- In firebird-support@yahoogroups.com, Svein Erling Tysvær
<svein.erling.tysvaer@k...> wrote:
> --- In firebird-support@yahoogroups.com, "Nigel Weeks" wrote:
> > Our application(powered by Firebird 1.5) is running slightly slow.
> > I did a 'top' command, and got a screenshot, but I'm not sure if it
> > needs
> > more:
> > Memory
> > CPU
> > Swap space
> > faster disk IO
> >
> > If anyone's able to diagnose a top listing, can they let me know?
> >
> > (I don't want to send a 55k gif image to everyone on the list...)
> >
> > Nige.
>
> Hi Nigel,
> don't worry about the 55k gif image, this list doesn't allow
> attachments anyway...
>
> I'm not amongst those able to diagnose a top listing (I don't even
> know what it is), nor do I know much (if anything) about memory, CPU,
> swap space or disk IO. What I do know a bit about is queries and plans
> and the first place to start checking if things are running slow
> (well, at least from the point of a hardware ignorant) is to check the
> gap between the oldest active transaction and the next transaction,
> and if that gap isn't too big, see if it is possible to identify a
> slow query and post the query and it's plan to this list (or solve it
> yourself if the problem is easy to spot).
>
> If you've already done these things, then it may be time to consider
> what you mention (as well as page size and operating system?).
>
> Set