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]