Home > Blogs > VMware VROOM! Blog


Database Sizing Charts for vSphere 4.0

Many of our customers have databases running on proprietary hardware that is approaching end of life. Often these databases are not considered as candidates for virtualization due to the fact that they are running on larger systems with more sockets while x86 systems have fewer cores and virtual machines often have even lower vCPU limits. Advances in processor technology however often place the performance of a VM with a smaller number of virtual processors at par with a lot of these much larger systems.

In this document, we introduce capacity planning and sizing charts for databases in a virtual environment. The purpose of these charts is to aid in sizing of databases which are being moved from a legacy RISC based physical machine to virtual machine running on a modern x86 based system running VMware vSphere.

We combined a set of data from both experiments in the lab and published throughput results to derive a VMware conversion metric from older RISC machines. The data should be used to identify potential candidates of database servers which can easily be virtualized, and to then perform first order sizing for those virtual machines.

The following table provides an estimated capacity planning reference for aggregate database throughput compared to the performance of a virtualized database running on a reference system.

The reference system used for this chart is an Intel Nehalem 2 socket 8 core system, as measured in the in the “Virtualizing Performance Critical Database Applications in vSphere 4” paper. The reference system has a VMware DBunit throughput of approximately 1000 per core, for a total capacity of 8000 with 8 cores. We’ve assumed near linear scalability in the first version of these tables.

The table may be used two ways:

  1. To calculate if the largest VMware virtual machine is large enough to accommodate the database from the physical RISC system.  The “Number of RISC Processors…” column shows the number of sockets in the largest system that an 8-vcpu VMware VM can replace for that machine type. Items denoted with a * indicate that the virtual machine is larger than the biggest physical system for that range.
  2. As a sizing estimator. “VMware DBunits” is the number of processing units needed for each RISC CPU in the source physical system. To calculate how many virtual cores are required to replace a physical system, simply multiply the number of processors (sockets) in the physical system by the DBunit score, and then divide the result by the processing capacity of the reference core (1038 for our Nehalem reference system).

As an example, a Sun E1290 system with 8 1.5Ghz USIV+ processors would require a DBunit of 8 x 723 = 5784.  Rounded up, this would require a virtual machine with 6 cores, thus a 6-vcpu VM would be required for equivalent processing capacity and headroom.

More often than not, the physical system is less than 100% utilized, because significant headroom is required. With virtualization, much less headroom is required, since if the virtual machine needs more processing capacity, it can simply be reconfigured with a larger number of processors. If we assume that the source physical system is at most 35% utilized, then we can run the same database in a virtual environment using only 2024 units, which is accommodated by 2-vcpus.

This is the first public version of this table. I'll update it as we gather more information and feedback on its use.

Table of RISC Throughputs
compared to a virtual machine (Version 1.1, April 2009)

 

 

Vendor

CPU and System Type

VMware DBunits
per RISC Processor

Number of RISC Processors replaced by one
8vcpu VM

Sun

Ultra Enterprise Server 450 – 250Mhz

100

4*

Sun

e10k – 250Mhz

48

64*

Sun

e10k 464Mhz

156

53

Sun

E6000-250

45

30*

Sun

E4500 – 464Mhz

166

14*

Sun

E4800   1.2Ghz USIV

402

14*

Sun

E6800 – 1.2Ghz USIV

402

21

Sun

E1280   1.2Ghz USIV

402

21

Sun

E4900   1.5Ghz USIV+

723

11

Sun

E6900 – 1.5Ghz USIV+

723

11

Sun

E1290   1.5Ghz USIV+

723

11

Sun

E15k – 900Mhz

166

50

Sun

E15k – 1.2Ghz

186

45

Sun

E15k – 1.2Ghz USIV

335

25

Sun

E15k – 1.5Ghz USIV+

603

14

IBM

IBM eServer pSeries p690, Power4, 1.3 Ghz

726

11

HP

HP Superdome PA-RISC/875 MHz

297

28

HP

HP Integrity Superdome Server, Intel
Itanium

710

12

 

* Capped by
max physical CPUs supported by system

 

This entry was posted in Uncategorized on by .
Richard McDougall

About Richard McDougall

Richard McDougall is the Big Data and Storage Chief Scientist at VMware. He is working on advanced development and analytics for core vSphere storage and application storage services, including Big Data, Hadoop. Prior, as the Chief Performance architect Richard drove the performance strategy and initiatives to enable virtualization of high-end mission critical applications on VMware products. Prior to joining VMware, Richard was a Distinguished Engineer at Sun Microsystems. During his 14 years at Sun, he was responsible for driving high performance and scalability initiatives for Solaris and key applications on the Sun platform. He served on the central software platform architecture review committee, and also drove the early resource management initiatives for Solaris. Recognized as an operating system and performance expert, he developed several technologies for the Solaris operating system and co-authored several books—including “Solaris Resource Management”, “Solaris Internals” and “Solaris Performance and Tools”. Richard holds several patents in the area of performance instrumentation, algorithms and distributed file system technologies.

10 thoughts on “Database Sizing Charts for vSphere 4.0

  1. Mark

    Rich, great info. There are some minor errors. E4800 is 12 max processors, not 14. V1280 also is 12 processors max. The E1290 should be called the E2900.
    Please add more IBM Power4 (p650) and Power5 (p550, p560), and HP PA-RISC (3400, 4400, 7400) and Itanium (3600, 6600, and 7600) midrange systems. Also Sun V480/490 and V880/890.
    Thanks.

    Reply
  2. MrBenchmark

    This is a brave attempt. However, there are many types of database workloads and attempting to generalize ALL DB workload with one set of number is misleading. You need to be more specific to be credible ! Also, comparing to 15 years old system is unfair. You should compare with systems currently on the Sun or HP catalog.

    Reply
  3. Joe Williams

    As VMWare matures to be a company that understands enterprise and especially enterprise database workloads hopefully we will see fewer of these simplistic and inaccurate posts ?
    As a VMWare customer I would rather see usable, real world guides than fud.
    As competition for VMWare increases in the market it is a real shame to see VMWare’s standard response turning towards fud rather than customer focused solutions.

    Reply
  4. Richard McDougall

    Benoit, Joe,
    Thanks for your comments.
    I agree that there are different types of database workload, and that system throughput can be a function of those different workload patterns. However, that is not mutually exclusive with consolidated metrics for capacity planning purposes.
    Consider the widely used IBM rPerf and Sun M-Values. These tables are used specifically as a guideline to help make system selections when upgrading from one system to another, and have been used heavily over the past two decades for this purpose. The Sun M-values also made it into some well known capacity planning tools (from BMC and Teamquest).
    The figures here are relative performance ratios to help selection when migrating workloads on older systems to virtualized architectures.
    The matrix provided here is comprised of a geometric mean of several standard benchmarks, as used in the IBM rPerf and Sun M-Value charts, and are appropriate for the purpose of first order capacity planning.
    We hope to expand this matrix into a similar set of tables for our customers, as IBM and Sun did with their relative performance comparison charts.
    Richard.

    Reply
  5. Robb

    I want to know if VMware has produced a sizing tool for provisioning both Hosts and VMs across various server hardware and storage platforms? I have been using rules of thumb, and adding a bit for scaling, and I have had a look at the HP sizing tool, but its not really relevant for my purposes. Apart from using my own experience, I had hoped to find a tool that would enable me to enter my requirements and extract a sensible and practical result that would enable me to plan and document my HLDs and LLDs.

    Reply
  6. Don V

    So – has there been any additional work on this kind of cross-platform -to- VM migration?
    Trying to move a large number of AIX hosts to Linux-based VM counterparts and there’s simply no tools out there to assist. I’ve got all the rperf data from AIX via NMON, but I have no clue how to turn that into a hardware proposal to support the required target VMs

    Reply
  7. Pingback: Welcome to vSphere-land! » Performance Links

  8. Pingback: vSphere content links, an attempt at consolidation. | vBrainstorm.com

Leave a Reply

Your email address will not be published. Required fields are marked *

*