Hello, > 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.
The DefaultDbCachePages parameter in firebird.conf applies when page buffers of the database is set to 0. > It seems to be still not solving this problem using by FileSystemCacheSize. > > What else can I test? I haven't followed the entire thread, but first I would rule out I/O problems like faulty RAID controllers etc. In a particular case I was called, although a high-end server in that case, performance was worse than on an oldish laptop. Then there are various tuning/optimizations techniques and settings, which I usually discuss and go through at customer sites. Page size, page buffers, hash slots, increasing RAM usage for the sorting module etc. Once the tuning/configuration side is exhausted, SQL tuning is probably the most important thing. At least from my experience. For sure, I would move away from SuperServer to Classic or SuperClassic to get an overall increase in CPU utilization in a multi-user environment. Although e.g. gbak is still bound to a single core. -- With regards, Thomas Steinmaurer http://www.upscene.com/ Professional Tools and Services for Firebird FB TraceManager, IB LogManager, Database Health Check, Tuning etc. > > <<< 22.01.2014 15:05 - Hugo Eyng "hugoe...@msn.com" >>> > > > 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 "hugoe...@msn.com" > <mailto:hugoe...@msn.com>>>> > > > 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 > "fabi...@sci10.com.br" <mailto:fabi...@sci10.com.br>>>> > > > > 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 > >
