'So the only effective solution seems to disable the random access request
(i.e. remove the FILE_FLAG_RANDOM_ACCESS flag) from the Windows API calls
used to create/open the files. Moreover, in this case the file-system cache
size limit should not be actual anymore, as Windows won't be expanding the
cache out of the reasonable boundaries. The quick tests prove this solution
being workable.'
.......
'Taking this into account, as well as the experience of other databases,
this solution has been committed into Firebird 2.1.5, Firebird 2.5.2 and
Firebird 3.0 branches.'
This made me assume this issue wasn't the cause of our problems. However by
the sounds of it the fix might not be working.
We are using Windows 2008 R2 64 bits, with databases around 35 Gb, and we
solved the performance problems with FB 2.5.2. We tested it before and after
apply the patch in 2.5.2 versión and verify that the problems was gone.
I thin you have to look up in other direction.
[Marius Labuschagne]
We have sites running Windows 2008 R2 64bits (Xeon Quad Core E31220 @ 3.1
Ghz) , with much smaller databases (2-4GB Range), and on Firebird Super
Server 2.5.2, and I can tell you that that platform is definitely much much
slower in performance than just a simple I3 desktop pc with 8GB of RAM on
the exact same database, running Windows 7 Pro or Windows 8 Pro, either 32-
or 64-bit.
I think you are very lucky Jesus that your problem was solved by 2.5.2
Example: Executing the Month-End in our application, exact same database:
- On a Win 2008 R2 64-bit Xeon Machine with 8GB RAM: 55 Minutes
- On a Win 7 Pro 64-bit I3 machine with 8GB RAM: 9 Minutes
For that specific platform 2.5.2 has not done anything for the performance
issue. I suppose we are also lucky that our Clients database is not larger
than the physical RAM present at this point in time, hopefully once they do
get there I will be able to convince the Client that just using a desktop
computer with a standard desktop operating system, is the way to go.
My 2c
Regards
Marius
