There are other things that should be considered, specially when you compare two different hardwares. For example, I know there are some DELL servers being sold with disk controller with *no cache*! This would be terrible (regarding performance) when running a database server.
So, the Windows cache problem is not the only factor that needs to be considered for differences in performance. The only 100% correct way of blamming the OS in your case, would be installing Win 7 in that same machine running Win2008, and compare. Carlos Firebird Performance in Detail - <http://videos.firebirddevelopersday.com> http://videos.firebirddevelopersday.com <http://www.firebirdnews.org> www.firebirdnews.org - <http://www.FireBase.com.br> www.FireBase.com.br '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 [Marius Labuschagne] Hi Carlos, I think you might be referring to my post re the Operating Systems. If you are, we have indeed tried exactly what you said. Loaded Win 7 onto that same machine (Xeon), same database, and indeed the resulting performance was on spec with what we would have expected on a machine of that spec. Regards Marius
