[AccessD] The Business Side Of Databases

Hi John:

Memory is key but after that both servers just run full-time each with a
different intranet IP address...re-directed access from the Router. If you
access the server as a station there is a dramatic performance drop but if
the servers are set as just servers, remote server-based access shows a
minimum performance drop. (Once setup with Linux you can just turn-off the
graphical interface for better performance.) Had a test running for a while
but for a hardware failure and was using MS's free Virtual Server software
but I hear VMWare is equally as good and runs on Linux as well. 

Jim   

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Thursday, June 28, 2007 10:52 AM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] The Business Side Of Databases

Do you have any idea what the overhead is for doing this?  I know that
Windows 2003 Standard Edition cannot utilize more than 4 gb of RAM.  If I
ran two virtual machines could I assign 4 gig to each virtual machine and
use all of the memory?  And how much overhead is there switching between the
machines?  If (for example) two virtual machines ran all of the time, each
running a SQL Server instance, would the overhead be 10%?  20%?

Could the base machine run Linux (for the low overhead), and the virtual
machines run Windows 2003 and SQL Server 2003?

John W. Colby
Colby Consulting
www.ColbyConsulting.com 
-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Eric Barro
Sent: Thursday, June 28, 2007 1:33 PM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] The Business Side Of Databases

With the 8 cores and tons of memory you should look into VMWare for virtual
servers. That way you can easily restore a virtual server should the need
ever arise. You can even set one or two VMs up to be test machines, etc... 

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Thursday, June 28, 2007 10:25 AM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] The Business Side Of Databases

Well, I like the slower machine idea!!!  Great minds think alike.  In fact I
am searching EBAY for some old Commodore 64 machines to make my servers.
;-)

Seriously though, I have no idea how to calculate FLOPS, never mind the fact
that FLOPS stands for FLOATING POINT operations per second.  So do you mean
FLOPS committed to a specific process or time scaled by FLOPS capability of
the specific machine?  Then you get into "what about disk access time", and
"speed of network connection" and whatever you can think of.  

In fact I used an "older" machine (a single core AMD X64 @ 3.0 GHz with 3 GB
ram BTW) to run the address validation because that process required a LOT
of memory and thus choked when run on one of my newer machines running SQL
Server.  SQL Server tends to grab all of the memory for itself and needs a
lot anyway.  Thus the "older" machine is not a slacker by any means, it is
just not one of my new dual core SQL Server machines.

For the moment I am just using crude manual adjustments of the $/hour for a
specific job.  I can make that more or less depending on the machine on
which the job runs.  I am logging the machine that runs the job.  

I do like the idea of using a FLOP calculation though.  This fall I will be
buying another server with 8 cores and a ton of memory.  Obviously the cost
of, and thus the value of time on a machine is related to it's power so
knowing the power of the machine and charging based on the machine
processing power will make sense.  Thanks for mentioning that.

John W. Colby
Colby Consulting
www.ColbyConsulting.com

-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com