RE: Anyone Running Oracle on VMWare?

  • From: "Crisler, Jon" <Jon.Crisler@xxxxxxx>
  • To: "Allen, Brandon" <Brandon.Allen@xxxxxxxxxxx>, <oracle-l@xxxxxxxxxxxxx>
  • Date: Wed, 14 Apr 2010 17:05:17 -0400

We do have extensive resource limits on place.    Although there is some
minor cpu / memory overhead , the real bottleneck seems to be I/O
overhead.     As for running Oracle on a dedicated VMware host, that
seems like a lot of effort just to get VMotion capabilities;  if your
not going to share with other guests, then our business model does not
lend itself to VMware at all.  We have some customers that actually want
that capability and have done it, but they are the exception rather than
the rule.

 

Speaking of resource limits- lets say you have an 8 cpu box with many
guests.  Two guests, each with 2 cpu's assigned, are running hard and
bumping against the limits, while the other guests are idle.  Memory is
not overallocated- it's a 1 for 1 allocation.  Now, with those two
guests running hard, you would think that they would not cross the
equivalent of 4 cpu utilization, but in reality the overhead of Vmware
forces far more than the equivalent of 4 cpu's-  Perhaps 5 or even 6
cpu, or as much as 50% overhead in this situation which is actually
pretty typical of our installs.  This condition seems to occur mostly
with databases and heavy I/O, and happens on Windows as well as RedHat
Linux 4 and 5.    For workloads that are mostly memory and cpu bound, we
do not see this behavior, but if you get a workload that also has heavy
I/O like a database, the vmware overhead really goes up.   We have tried
different HBA's, drivers, SAN storage, i/o scheduler tuning etc without
success.  The funny thing is that we see the same behavior on Windows
and Linux, and it happens on Oracle, SQL Server and MySQL.   At this
point we just chalk it up to the nature of the beast: that's how VMware
works in that environment.   Sure, I see white papers that say VMware
can deliver 97% of the I/O throughput of a native machine, but we cannot
duplicate that in our labs.  But I am not a vmware guru so I cannot
comment on the causes / fixes, other than the empirical results.   In
cases where we put web servers or application servers on vmware they
work great.

 

I think VMware is a great solution if used carefully and within its
limitations.

 

From: Allen, Brandon [mailto:Brandon.Allen@xxxxxxxxxxx] 
Sent: Wednesday, April 14, 2010 4:14 PM
To: Crisler, Jon; oracle-l@xxxxxxxxxxxxx
Subject: RE: Anyone Running Oracle on VMWare?

 

Our production DBs run on dedicated VMWare hosts, so there is no
contention with other virtuals.  But, I believe VMWare has functionality
to restrict the resource usage for each virtual host in order to prevent
the kind of problems you're talking about.  I'm not a VMWare admin, so
I'm not sure on exactly what functionality is available or how well it
works, but have you (or your VMWare admins) looked into it?

 

I haven't found the overhead of VMWare itself to be very significant -
maybe 1-5%, which could be significant if you're pushing your hardware
to the limit to begin with, but in that case you probably need better
hardware (or tuning to lighten the load) anyway.

 

 

From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Crisler, Jon

 

1)      Performance can be variable- depends on the load of the other
guests, and vmware itself has significant overhead.  We discourage
putting production databases on vmware due to this issue.  It can be
difficult to tune Oracle on vmware due to the effect of other guests. 

 

________________________________

Privileged/Confidential Information may be contained in this message or
attachments hereto. Please advise immediately if you or your employer do
not consent to Internet email for messages of this kind. Opinions,
conclusions and other information in this message that do not relate to
the official business of this company shall be understood as neither
given nor endorsed by it.

Other related posts:

  1. Home
  2. oracle-l
  3. Archive
  4. 04-2010