1

In the factory where I work there is an Hp ProLiant ML350 G6 with VmWare installed, only hosting a Windows Server 2000 Virtual machine (4Gb ram and 5GHz max CPU). All our PCs (30-40) connect to some DBs on this machine using a very old VB6 application. That's it.
The virtual machine is used just for access to DBs and some data.

Our problem is the fact that this machine can't hold all that traffic, the CPU (5GHz max) is always at 100% usage causing all kinds of trouble.
We have another virtual machine (12Gb ram and 21GHz max CPU) with Windows Server 2008. My plan is to transfer all the files we need on that VM to avoid the CPU problem. My colleague however doesn't believe in virtual machine (he says that virtual machine are at least 50% slower then a physical server) and so he would format the entire machine, clone a copy of the actual server (data and active directory) and then install it on the cleaned server.
The second solution of course costs more money and could end badly if the cloning process doesn't work.

What can we do? Is the difference between Virtual server and physical so big to justify all the trouble?

EDIT : We use 4 monstrous Access 2003 .mdb with a lot of plain stupid "Select * ...:"

SilentRage47
  • 125
  • 5
  • 4
    "Is the difference between Virtual server and physical so big to justify all the trouble ?" No. – mfinni May 30 '14 at 15:40
  • Can more physical resources be assigned to the guest? – Keith Stokes May 30 '14 at 15:49
  • 9
    `My colleague however doesn't believe in virtual machine (he says that virtual machine are at least 50% slower then a physical server) and so he would format the entire machine, clone a copy of the actual server (data and active directory) and then install it on the cleaned server.` Sounds like your colleague is volunteering to own this mess. Let him. That way when it blows up in his face, you should be out of the blast radius. – HopelessN00b May 30 '14 at 15:52
  • 3
    Hardware can't fix bad code. – joeqwerty May 30 '14 at 16:22
  • 2
    You got some fast CPUs there. – inf May 30 '14 at 16:57
  • 2
    50% slower huh? I wonder how he was able to determine that. Sounds like someone who deflecting with lack of knowledge. – DanBig May 30 '14 at 17:04
  • 2
    *My colleague however doesn't believe in virtual machine* - Believe? He "doesn't believe" in them? Luckily, IT is a science, rather than a religion, so he should be able to prove this "belief" with a few simple empirical tests. Or, y'know, not be able to prove it at all and learn something. *(con't...)* – Rob Moir May 30 '14 at 19:37
  • 1
    *(...con't)* As you can tell, I'm part of the camp here that wouldn't agree with that viewpoint. Though in fairness it is just about *possible* that some part of your particular workload doesn't play nice when virtualised (not *very* likely. and this would be an issue with the workload, not the overall practice of virtualisation). Which brings us back to testing and evidence really, doesn't it? – Rob Moir May 30 '14 at 19:40
  • Can't your data be sharded? It seems like that at the moment that machine is a single point of failure, and given that is always under heavy load, it's pretty much a catastrophe waiting to happen. – Pedro Rodrigues May 30 '14 at 23:35
  • @bamboon OP: You sure that's not 2.1 gHz? – Simon Kuang May 31 '14 at 05:56
  • @SimonKuang Most likely the OP is just adding up the frequency of each core. So when he says 21GHz he probably means an 8 core @ 2.6 GHz processor – Pedro Rodrigues Jun 02 '14 at 16:10
  • I'm with joeqwerty on this one. The problem isn't a hardware issue. Until you're ready to do something about your poorly designed application, these problems are going to continue regardless of what hardware solution you use. – John Homer Jun 03 '14 at 13:51

2 Answers2

10

My colleague however doesn't believe in virtual machine (he says that virtual machine are at least 50% slower then a physical server)

Tell your colleague to - ah - read up on that. 2%-3%. 50% was true once upon at time, when virtualization was not a function that the processor does natively and thus a lot of kernel level code had to be emulated.

That was around - hm - 10 years ago or so. Since then pretty much every processor has support for virtualization right in the hardware.

I would keep things on a VM but start upgrading - significantly - until the VM has enough ressources to deal with it.

TomTom
  • 51,649
  • 7
  • 54
  • 136
5

Here I found a doc comparing a physical/virtual Database Server with VMware vSphere 4 (newer versions have better performance) Performance and Scalability of Microsoft® SQL Server® on VMware vSphere™ 4 You see that performance difference is below 10% and with newer versions of vSphere I think its below 5%.

Are you sure cpu usage is just your db server software?

stefan.kress
  • 91
  • 1
  • You can crush the CPU on any database server with a single bad query. With 40 clients connecting to an old version of SQL server, using an old version of VB, I'm not surprised at all that they're managing to crush a database server... doesn't sound like a whole lot of care and maintenance has been put into this app (or infrastructure), so it's not going to be optimized or tuned, and is long past its useful life anyway, all of which is only going to make any underlying performance issues that much worse. – HopelessN00b May 30 '14 at 15:58
  • 1
    But blaming the VM is extremely - well, "not smart". Non-optimization and non-maintenance (heck, a Server 2000 - that will be hard to run on any decent hardware anyway) are likely the culprits, plus ridiculously underallocated ressources.... but then 2000.... that likely is still a 32bit server. – TomTom May 30 '14 at 16:00
  • 1
    @TomTom Yeah, Stefan's colleague clearly doesn't have even a whiff of a clue. – HopelessN00b May 30 '14 at 16:02