That is exactly what I'm doing right now. Its the only way to keep them going. I shut them down at lunch, run a sweep, then when they get back in, things are much faster.
-Josh On Tue, May 13, 2014 at 8:35 AM, 'Fabiano - Desenvolvimento SCI' [email protected] [firebird-support] <[email protected]>wrote: > > > 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:* [email protected] [mailto: > [email protected]] > *Enviada em:* terça-feira, 13 de maio de 2014 11:31 > *Para:* [email protected] > *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 > [email protected] [firebird-support] < > [email protected]> wrote: > > > > >I am a MSP for a large dental office that uses an application with a > Firebird DB. I've done a lot of database work in my life, > >but none with firebird so I need a little help with the configurations. > The office is complaining of slowness and what we've > >done so far to help them will be below. Keep in mind, I am not the > developer of the application, just a MSP trying to help > >them out since the developer has no clue what they're doing. > > > >We noticed the server would start pretty fast but then throughout the day > slow down. > > > >Thanks for any advice you can give. > > 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. > > HTH, > Set > > > > >
