|
I use SuperClassic and seted the
DefaultDbCachePages = 2250
The Default value is 75
Than I used a multiple of 75
The amount of memory used by FB service
increases a lot and the performance increases
too
Em 23/01/2014 02:52, Alexey Kovyazin escreveu:
Hi Roland,
>I have tried to change this parameter
(actually =20), but I don't see any change.
20? It is below all meaningful values.
If you are using SuperServer, set 10000, if
Classic or SuperClassic, set 1024, and
_restart_ Firebird.
>What else can I test?
If you are interested in professional
optimization (http://ib-aid.com/services/optimization), contact our support.
Regards,
Alexey Kovyazin
www.IBSurgeon.com
AFAIK, the parameter DefaultDbCachePages is
intended for newly created
databases as default size of cache pages. It
doesn't have effect on existing
databases where its own setting is used. Every
database can have own setting
about count of cache pages.
It seems to be still not solving this problem
using by FileSystemCacheSize.
What else can I test?
Thanks.
<<< 22.01.2014 15:05 - Hugo Eyng "hugoeyng@..." >>>
|
Try changing
values for DefaultDbCachePages
Em 21/01/2014 18:40, Roland Turcan
escreveu:
I have tried to change this parameter
(actually =20), but I don't see any
change.
My server box is:
Hewlett Packard server
Intel Xeon CPU E31220 @ 3.10GHx
10GB RAM (8 GB RAM is usable)
Firebird 2.5.2 64bit SuperServer
single database is being used
where its size is about 80GB
When I copy any big file to test the
performance of disk field then I can see
that it can force disk performance, but
Firebird is still relaxing.
When I try to backup database using
"gbak" no change. CPU core is on 3-6%
and disk
load is about 1MB/s
What can I check else?
Thanks in advance.
TRoland;
<<< 21.01.2014 15:17 - Hugo
Eyng "hugoeyng@..." >>>
|
I changed
the paramter FileSystemCacheSize
= 0 to FileSystemCacheSize = 20
in the firebird.conf
as suggested in:
http://dyemanov.blogspot.com.br/2012/03/firebird-vs-windows-file-system-caching.html
Hugo
Em 21/01/2014 12:06, Roland
Turcan escreveu:
Yes, I am interested too.
What was the key to get rid of
this problem?
Thanks in advance.
<<< 21.01.2014 15:29 -
Fabiano - Desenvolvimento SCI "fabiano@..."
>>>
|
How
you solved your problem?
De:
firebird-support@yahoogroups.com
[mailto:firebird-support@yahoogroups.com]
Em nome de Hugo
Eyng
Enviada em:
terça-feira, 21 de
janeiro de 2014 10:24
Para: firebird-support@yahoogroups.com
Assunto:
Re: [firebird-support]
Very very very slow FB
2.5.2 64bit performance
on Windows 2008 R2
Hi Helen.
Thanks for your
answer.
You are right.
But the "Windows 64
file cache
performance" was a
problem, as said Sean.
Só 'reserving' 10GB as
a RAM DRIVE grant that
I would have always
available RAM.
But now I solved the
'cache performance'
and I will not need
RAM DRIVE anymore.
Even so, the FB
performance is not
compatible to the
hardware used to run
it.
Em 20/01/2014 23:12,
Helen Borrie escreveu:
At 02:01 p.m.
21/01/2014, Hugo Eyng
wrote:
>As Firebird do not
use available RAM I
created a RAM DRIVE
with 10GB and pointed
parameter
'TempDirectories'
(firebird.conf) to
this RAM DRIVE, but FB
just uses it rarely in
very big 'SELECT'. OK,
when FB uses the RAM
DRIVE it increases a
SELECT speed in more
than 80%. I expected
FB could use this for
every SELECTS and so
improve the
application.
Fb uses RAM directly
for sorts, if enough
is available. It only
takes the sort sets to
disk if available RAM
is insufficient.
Helen Borrie, Support
Consultant, IBPhoenix
(Pacific)
Author of "The
Firebird Book" and
"The Firebird Book
Second Edition"
http://www.firebird-books.net
__________________________________________________________
--
Atenciosamente,
Hugo Eyng |
How you
solved your problem?
De: firebird-support@yahoogroups.com [mailto:firebird-support@yahoogroups.com] Em nome de Hugo
Eyng
Enviada em: terça-feira,
21 de janeiro de 2014 10:24
Para: firebird-support@yahoogroups.com
Assunto: Re:
[firebird-support] Very very
very slow FB 2.5.2 64bit
performance on Windows 2008 R2
Hi Helen.
Thanks for your answer.
You are right.
But the "Windows 64 file cache
performance" was a problem, as
said Sean.
Só 'reserving' 10GB as a RAM
DRIVE grant that I would have
always available RAM.
But now I solved the 'cache
performance' and I will not need
RAM DRIVE anymore.
Even so, the FB performance is
not compatible to the hardware
used to run it.
Em 20/01/2014 23:12, Helen
Borrie escreveu:
At 02:01 p.m. 21/01/2014, Hugo
Eyng wrote:
>As Firebird do not use
available RAM I created a RAM
DRIVE with 10GB and pointed
parameter 'TempDirectories'
(firebird.conf) to this RAM
DRIVE, but FB just uses it
rarely in very big 'SELECT'. OK,
when FB uses the RAM DRIVE it
increases a SELECT speed in more
than 80%. I expected FB could
use this for every SELECTS and
so improve the application.
Fb uses RAM directly for sorts,
if enough is available. It only
takes the sort sets to disk if
available RAM is insufficient.
Helen Borrie, Support
Consultant, IBPhoenix (Pacific)
Author of "The Firebird Book"
and "The Firebird Book Second
Edition"
http://www.firebird-books.net
__________________________________________________________
--
Atenciosamente,
Hugo Eyng
--
Best regards, TRoland
http://www.rotursoft.sk
http://exekutor.rotursoft.sk
--
Atenciosamente,
Hugo Eyng |
--
Best regards, TRoland
http://www.rotursoft.sk
http://exekutor.rotursoft.sk
--
Atenciosamente,
Hugo Eyng |
--
Best regards, TRoland
http://www.rotursoft.sk
http://exekutor.rotursoft.sk
--
Atenciosamente,
Hugo Eyng
|