<<< 23.01.2014 9:11 - Thomas Steinmaurer "ts@..." >>>
TS> Hello,

Hello Thomas,

>> 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.

TS>
TS> The DefaultDbCachePages parameter in firebird.conf applies when page
TS> buffers of the database is set to 0.

Thanks for this info. This is not described as you write in
firebird.conf.

>> It seems to be still not solving this problem using by FileSystemCacheSize.
>>
>> What else can I test?

TS>
TS> I haven't followed the entire thread, but first I would rule out I/O
TS> problems like faulty RAID controllers etc. In a particular case I was
TS> called, although a high-end server in that case, performance was worse
TS> than on an oldish laptop.
TS>
TS> Then there are various tuning/optimizations techniques and settings,
TS> which I usually discuss and go through at customer sites. Page size,
TS> page buffers, hash slots, increasing RAM usage for the sorting module
TS> etc. Once the tuning/configuration side is exhausted, SQL tuning is
TS> probably the most important thing. At least from my experience.

I have generated a big database about 50GB in my development computer
having 16GB RAM Win7 64bit and usual SATA drive. I use Firebird 2.5.2
Classic 64bit and I have the same behavior as on that server I
mentioned initially.
It seems to be still problem even I use 2.5.2 where CORE-3791 is
implemented.

TS> For sure, I would move away from SuperServer to Classic or SuperClassic
TS> to get an overall increase in CPU utilization in a multi-user
TS> environment.

Yes, I know this. Usually I use single database deployment and
therefore is Classic better for me.

TS> Although e.g. gbak is still bound to a single core.

Of course.

TS> --
TS> With regards,
TS> Thomas Steinmaurer
TS> http://www.upscene.com/
TS>
TS> Professional Tools and Services for Firebird
TS> FB TraceManager, IB LogManager, Database Health Check, Tuning etc.
TS>

>>
>> <<< 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@..."
>> <mailto: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@..." <mailto:fabiano@...>>>>
>>
>>
>>
>> How you solved your problem?
>>
>> *De: *firebird-support@yahoogroups.com
>> <mailto: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
>> <mailto: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>[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
>> <mailto: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
>>
>>

TS>
TS>
TS>
TS>




--
Best regards, TRoland
http://www.rotursoft.sk
http://exekutor.rotursoft.sk