Subject | Re: Optimum DefaultDbCachePages/Buffers for Server |
---|---|
Author | Tom Conlon |
Post date | 2007-06-24T11:47:22Z |
The problem has been located in a key trigger and appears to be sorted.
The first line support at the company in question reported 'the system
was slow throughout' - incorrect information which goes to show one
has to get the correct information always.
Getting back to the original question, surely someone has some advice
regarding the values to use - please?
so far:
have tried DefaultDbCachePages=8192 (no other .conf values changed)
then later
explicitly set it at the database level using gfix buffers=10000
With the spec of the server would it be advised to increase these
values at all?
Thanks,
Tom
--- In firebird-support@yahoogroups.com, "Ivan Prenosil"
<Ivan.Prenosil@...> wrote:
The first line support at the company in question reported 'the system
was slow throughout' - incorrect information which goes to show one
has to get the correct information always.
Getting back to the original question, surely someone has some advice
regarding the values to use - please?
so far:
have tried DefaultDbCachePages=8192 (no other .conf values changed)
then later
explicitly set it at the database level using gfix buffers=10000
With the spec of the server would it be advised to increase these
values at all?
Thanks,
Tom
--- In firebird-support@yahoogroups.com, "Ivan Prenosil"
<Ivan.Prenosil@...> wrote:
>setting number of buffers :)
> > What would be the recommended DefaultDbCachePages (or Buffers) values
> > to use in the following situation?
> ...
> > Having recent performance issues. A number of new processes from a
> > third party are accessing the main database plus MSSQL Server (using
> > 152MB memory)/Javaw/backup (be*.exe) services are installed but have
> > been there for quite some time 'without any problems'.
> >
> > Swept, Validated ok, backed up and restored but system is crawling and
> > this is now a big problem. Any ideas anyone?
>
> If it was that easy and all performance issues could be solved by
> You can try to tune number of buffers yourself to get betterperformance,
> but it is unlikely that it will solve situation described like"system is crawling"
> and "big problem". You have to identify the main reason of theslowness first
> (stuck transactions, committing every single operation, badly optimizedtriggers, ...)
> queries, too much/too few indexes, unexpected side effects of
>
> Ivan
>