| Subject | RES: [firebird-support] Cache Performance Options |
|---|---|
| Author | Fabiano - Desenvolvimento SCI |
| Post date | 2014-05-13T14:35:51Z |
Large gap is not caused by lack of auto sweep. It is bad system design.
As you is not the system programmer, you can shut down all connections to the database during lunch time, then you can let users enter in your system again.
After shutting down, run a manual sweep (gfix –sweep). If you see a increase in performance, your system is bad transaction designed.
De: firebird-support@yahoogroups.com
[mailto:firebird-support@yahoogroups.com]
Enviada em: terça-feira, 13 de maio de 2014 11:31
Para: firebird-support@yahoogroups.com
Assunto: Re: [firebird-support] Cache Performance Options
Set,
There is a large gap because I turned off auto sweeping. I disabled it because when it was sweeping, it was killing performance even more. Previous to the 2.5.2 update, it was also using all the memory and causing the server to swap every time it did a sweep (20,000 transactions). Right now, I have it sweeping once during their lunch downtime and again at the end of the day. It is faster than before the 2.5.2 update, but still not fast.
-Josh
On Tue, May 13, 2014 at 12:18 AM, Svein Erling Tysvær svein.erling.tysvaer@... [firebird-support] <firebird-support@yahoogroups.com> wrote:
an application with a Firebird DB. I've done a lot of database work in my life,>I am a MSP for a large dental office that uses
>but none with firebird so I need a little help with the configurations. Theoffice is complaining of slowness and what we've
>done so far to help them will be below. Keep in mind, I am not thedeveloper of the application, just a MSP trying to help
>them out since the developer has no clue what they're doing.slow down.
>
>We noticed the server would start pretty fast but then throughout the day
>A slow database can have lots of reasons, Josh. I take it that the 'large dental office' is amongst the largest companies that use the application in question, either in terms of database size or number of simultaneous users? Your observation that things slow down gradually, indicates that one possibility is that the developer hasn't thought thoroughly enough about transactions (a vital part of Firebird). Try running gstat when the database is slow, maybe you will see a large gap between oldest and next transactions.
>Thanks for any advice you can give.
HTH,
Set