Subject R: [firebird-support] Firebird performance issues on VM platform
Author Paolo Fainelli
i had the same problem under Wmware vSphere. After virtualizing the
server, WRITE performance was orrible , but it seems a WMware issue,
not Firebird ( buffer flush).
Modifing firebird.conf (ForcedWrites=Off , MaxUnflushedWrites = 100,
MaxUnflushedWriteTime = 5) write performance are now very similar to
original server.


Hi Firebird support

I am contacting you in desperation hoping you could please try to assist
I am not the developer, but I have cc'd my developer, who could answer
technical questions if required.

We recently moved/migrated our hosted server (physical server) to a VM
platform - we are now running Windows Server 2008 R2 64 bit OS. We have
found the performance of Firebird to be lacking on this OS / VM
We have tried increasing the physical resources, but this does not help.
have run IO tests on disk access speed, which resulted in only 3 Gb/sec
access speed. The supplier who hosts this VM server has no idea what to
to fix the access speed.

We are currently using:

. Firebird 2.1.3 18185 - 64 bit (super server) - have also tried
classic server, but shows no difference in performance

. OS - Windows Server 2008 R2 - 64 bit

. Our applications are mostly developed in Delphi - on this server
we host a web based data warehouse for POS transactions (replication
process), as well as a centralized database management for restaurant

The opportunity:

. Slow response time for processing of display of web page data
warehouse, once we run another application that utilizes firebird, our
customers cannot access anything. Firebird does not seem to be
when we look at the cpu/mem usage though? Runs at about 50% cpu max.

What we had before that worked:

. Physical hosted server, quad core, 8Gb RAM, Windows Server 2008 R1

Are there any tweaks or configuration settings/differences in Windows
2008 R2 we need to make using the new OS with Firebird?

I hope I have provided enough info, if not my developer will have to
step in
to answer these - Many thanks!


Mike Kenyon