Hello,
This is of great interest to me since we are just about to do the same thing. I have been doing some analysis of the IO on our current production windows 2003 servers. I have discovered something quite alarming that may explain why you are getting poor performance on a VM
I looked at how much data the firebird processes (classic fbinet_server) were actually writing to disk. I discovered that it was gigabytes of data for relatively small databases.
You can see this by using windows task manager and turning on the IO Write and IO Write Bytes columns on the processes tab.

It appears to me that every time a select query is run the firebird process writes data to disk. I have posted a separate thread about this hoping that someone may be able to explain why this happens and why it is so much.

--- In firebird-support@yahoogroups.com, Kenneth Watson <kenw@...> wrote:
>
> Hi
>
> Thanks for your reply.
>
>
> > -- Are you getting actual 8GB physical RAM now, or are you mostly in
> swap?
>
> The VM has 4Gb RAM allocated at the moment. From the looks of things,
> we're using at most 1.5Gb of that at the moment, Windows "Paginf File" %
> Usage monitor/counter seems to indicate we're using ~0.25% of the 4Gb PF.
>
> > -- Is page cache configured on the assumption that Firebird still has
> oodles of RAM available? (Page cache is determined as page_size * no.
> of pages).
>
> Firebird DOES have oodles of RAM, it seems to refuse to use much of it
> though. Maxing out at ~70-80mb RAM usage under heavy usage.
>
> > --hopefully your database partition is excluded from System Restore.
> If not, it needs to be.
>
> Honestly, I cannot even find any System Restore options in Win 2008 R2.
>
> > --has anyone meddled with firebird.conf and tried to force the
> engine's cpu affinity on more than one cpu? Alternatively, if the
> engine is configured for the default (cpu 0) and the VM's affinity is
> forced to another (or others)...might be a mess. CPU Affinity MUST be
> to one and only CPU for SuperServer.
>
> I did indeed muck with the CPU Affinity, tried assigning it to 2 and 3
> CPUs. This was only after we identified these performance issues, and
> I've since reset it. This was also a reason I tried the Classic Server
> (which had no impact).
>
> > --was the database file-copied onto the colocation server, or
> gbak-restored? (Could be lots of garbage there if it was file copied.)
>
> Yes, the DBs were simply copied. Interestingly, upon attempting to
> backup/restore a few ~300mb DBs, the operation takes around 8 minutes.
> The same operation on a slightly larger DB on my local PC takes 2 minutes.
>
>
> Another point regarding our setup is that we have multiple FDBs all
> reading/writing at the same time from various services (never writing to
> the same DB from more than one service though). I don't know if there's
> perhaps a way to optimise FB to better manage simultaneous access to a
> number of DBs. Perhaps multiple FB instances, each assigned to a
> different CPU core?
>
>
> Thanks,
>
> - Ken
>
>
> On 10/09/2010 05:04, Helen Borrie wrote:
> > At 09:36 AM 10/09/2010, Mike Kenyon wrote:
> >> 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 platform.
> >> We have tried increasing the physical resources, but this does not help.
> >
> > Compared to
> >
> >> What we had before that worked:
> >> Physical hosted server, quad core, 8Gb RAM, Windows Server 2008 R1
> >
> > how do the resources stack up?
> > -- Are you getting actual 8GB physical RAM now, or are you mostly in swap?
> > -- Did you have 7200 or 9600 rpm hard disk before on sub-terabyte HDDs, whereas now you are sharing space on a HDD>= 1 TB? (Curious about that as here in NZ, I haven't seen any TB-plus HDDs available w. rpm speeds faster or slower than this oddball "5700 rpm")
> > -- Is page cache configured on the assumption that Firebird still has oodles of RAM available? (Page cache is determined as page_size * no. of pages).
> >
> > Old-hat stuff:
> >
> > --hopefully your database partition is excluded from System Restore. If not, it needs to be.
> >
> > --has anyone meddled with firebird.conf and tried to force the engine's cpu affinity on more than one cpu? Alternatively, if the engine is configured for the default (cpu 0) and the VM's affinity is forced to another (or others)...might be a mess. CPU Affinity MUST be to one and only CPU for SuperServer.
> >
> > --was the database file-copied onto the colocation server, or gbak-restored? (Could be lots of garbage there if it was file copied.)
> >
> > This is by no means an exhaustive checklist, btw.
> >
> > Incidentally, though I cc-ed this to your tech colleague, don't expect this as normal for lists. If your colleague needs to see the responses, he'll need to subscribe himself...
> >
> > ./hb
> >
> >
>
>
> [Non-text portions of this message have been removed]
>