WHITEPAPER

Virtualized Databases:
Performance Considerations
for DBAs
WHITEPAPER: VIRTUALIZED DATABASES: PERFORMANCE CONSIDERATIONS FOR DBAS

Virtualized Databases:
Performance Considerations for DBAs
Background
Virtualization is now ubiquitous for x86 servers, but what about databases?
To answer this question, SolarWinds ran a THWACK survey to see the level of
® 1

virtualized databases within our user community and other characteristics related
to their database environment.

Figure 1 - Percent of databases running in a Virtual Machine (VM) – SolarWinds THWACK Survey

The results were on target with virtualization overall, with 87.4% of respondents
saying their databases ran in virtual machines.

When it came to which hypervisors were used, VMware was by far the most used
®

with 89.5% of respondents. Microsoft Hyper-V was a distant second with 28.7%
® ®

followed by Azure VM at 22%.

®

The next category in the survey covering the most virtualized databases was
interesting. Not only due to Microsoft SQL Server being the most virtualized at
93.3%, but the number of open source databases running in a virtual machine (VM).
MySQL was the third most virtualized database platform which is no surprise given
its growing popularity. PostgreSQL, MongoDB, and MariaDB ranked ahead of IBM
DB2 and SAP ASE (Sybase) showing the growth of open source.

1
SolarWinds THWACK Virtualized Database Survey 2020

page 1
WHITEPAPER: VIRTUALIZED DATABASES: PERFORMANCE CONSIDERATIONS FOR DBAS

Figure 2 – The most virtualized database platforms – SolarWinds THWACK Survey

The final and most telling result from the survey was the percentage of virtualized
databases, with the number of respondents who had 100% of their databases
virtualized at 24.4%. The results for the percentage of virtualized database instances
are as follows:

• 100% of databases virtualized 24.4%

• 50% to 99% virtualized 52.1%
• 50% or less virtualized 23.5%
Given the results of the SolarWinds THWACK survey are close to the various
industry estimates of 90%+ x86 server virtualization, the obvious conclusion is the
majority of database instances run on virtual infrastructure.

Virtualization’s Impact on the DBA

When it comes to application performance problems, all roads tend to lead to the
Database Administrator (DBA). For wrong or right, “the database is the problem”
and the DBA has to quickly find the culprit to performance issues. “Slow is the new
broke” is indeed an accurate description of the sentiment in many organizations.
Since there are many variables potentially affecting database performance from
poorly written SQL and T-SQL to resource constraints, the addition of virtualization
can make it more challenging for the DBA to find the root cause of performance
degradation. The goal of this whitepaper is to provide DBAs with the core concepts
and metrics potentially having the most impact on their database instances. In
addition, SolarWinds Database Performance Analyzer examples will be used to
®

show how performance management solutions integrating virtualization metrics

and data can simplify the process for determining the root cause of database
performance issues.

page 2
WHITEPAPER: VIRTUALIZED DATABASES: PERFORMANCE CONSIDERATIONS FOR DBAS

What a DBA Should Look For

How many times do DBAs face the following scenario? A complaint about database
performance comes in and at cursory glance—the database instance itself looks
fine, nothing changed within the database, and the SQL was running fine before.
Since the onus resides on the DBA, they need all the relevant data at their fingertips
including virtualization metrics and data.

The following metrics and data are those associated with VMware ESXI—the most
®

prevalent hypervisor used to host database platforms—noted in the results from

the THWACK survey.

CPU Ready
• This metric indicates the VM (and the database trying to run inside it) was ready
to run, but instead sat idle waiting behind other VMs contending to control the
same shared resources such as physical CPUs or memory.

• For example, a vSphere host has six physical CPUs, and two VMs are configured
to each require four virtual CPUs (vCPUs) before they can run. This situation
means only one VM can run at a time. You can eliminate the VMs queueing behind
each other by either moving a VM to another host or configuring both VMs to
require three or fewer virtual CPUs.

• The term “oversubscription” simply means you’ve assigned more

virtual resources than what physical resources exist to run all VMs
concurrently. It may seem a bit strange, but reducing the number
of vCPUs may dramatically increase its performance. Generally,
oversubscription shouldn’t go above 5%.

VM CPU Usage
• Actively used CPU as a percent of total available virtual CPU in the virtual machine.
Host CPU Usage
• Actively used CPU as a percent of total available CPU on the machine. If this
number is high you might see VMs with high CPU ready and/or co-stop.

• Active CPU is approximately equal to the ratio of the used CPU

to the available CPU where: Available CPU = # of physical CPUs x
clock rate.

Co-Stop
• When a VM has multiple vCPUs, this is the time spent to line up multiple vCPUs for
the simultaneous execution of a task. The higher the wait time (in milliseconds)
an executed task waits for a vCPU due to scheduling (lack of resources), the
worse the performance impact. Meaning your VM can be waiting on physical CPU
resources in use by other VMs. If you see high Host CPU Usage, this is probably

page 3
WHITEPAPER: VIRTUALIZED DATABASES: PERFORMANCE CONSIDERATIONS FOR DBAS

a sign there are too many VMs on this host and/or you need more physical CPU
resources. Also, you can look at reducing the number of vCPUs for the VM.

VM Memory Swap Rate

• The “swap in” and “swap out” rates generally mean you have a shortage of
physical memory on the host, so the memory is swapped in and out from disk.

VM Active Memory Usage

• This is the memory in use as a percent of the memory configured for the VM.
Host Memory Usage
• This is the memory usage on the host (consumed memory / total machine
memory). If this is high (e.g., GT 90%), this could indicate host memory over-
commit which could lead to high VM swap rates.

VM Memory Overhead
• This is the amount of memory used to run the VM. Over-configuring memory
(or excess vCPU for that matter) will unnecessarily increase overhead. This said,
there’s memory needed by ESXi itself and the virtual machine (virtual machine
frame buffer).

VM Memory Balloon
• The balloon driver reclaims pages on the server considered less valuable. The
crux of this VMware proprietary technique is to match the behavior of a guest OS.
You should only see this when the host is running low or out of physical memory.

• If you see the virtual machine your database instance is running in has a certain
percent of memory claimed by the balloon driver, look for memory swapping
which could affect your VM’s performance. However, if you don’t see any
swapping issues, you don’t and won’t necessarily have a performance problem.

VM Disk Commands
• Number of disk commands executed is an indication of how busy the disks are.
This said, unless you see large queues developing and aborted commands, there
isn’t a problem.

• If you see aborted disk commands, then your storage is severely overloaded and
this can lead to serious application response issues.

VM Disk Usage
• Available if you aren’t using an NFS datastore, it’ll show the average disk I/O rates
across all virtual disks on the VM.

VM Read / Write Rates

• VM disk read rate is the average amount of data read from the disk each second
during the collection interval. For a VM, this is the rate at which data is read from
each virtual disk to the virtual machine.

page 4
WHITEPAPER: VIRTUALIZED DATABASES: PERFORMANCE CONSIDERATIONS FOR DBAS

• VM disk write rate is the average amount of data written to disk each second
during the collection interval—the rate data is written to each virtual disk on the
VM.

Host Disk Device Read / Write Rates

• The host disk read-and-write rate is the average read/write rate across all disks/
LUNs on the host. The rate represents the read/write throughput at the host level
across all disks/LUNs and VMs running on the host.

• If the database instance has I/O performance issues, you may

have another VM on the same host causing the delays. Compare
this metric to the physical I/O rate from the database instance. If
the Host rate is higher, then it’s likely another VM is the problem.
Otherwise, the VM your instance is running in may cause too much
of a demand on the underlying physical storage.

Host Max Disk Latency

• This is the highest latency value across all disks used by this host.
Host Disk Latency
• Read latency is the average amount of time to process a read command to a disk
to the host (across all VMs). High disk latency indicates storage may be slow or
overloaded.

• Write latency is similar to read and is the average amount of time to process a
write command from the specific disk across all VMs.

• Disk Write Latency = Kernel Write Latency + Device Write Latency

• Expected disk latencies will depend on the nature of the storage like read/write
mix, randomness, and I/O size along with the capability of the storage subsystem.

All of these metrics can be found by executing the “esxtop” command from your
VMware ESXi host of from virtualization performance monitoring like SolarWinds
Virtualization Manager. The problem with using outside monitors such as these is
they don’t correlate to database metrics and in most cases are not accessible by
the DBA or are too complicated for a DBA to navigate and understand.

Database and Virtualization Performance Correlation With DPA

SolarWinds Database Performance Analyzer (DPA) is a database performance
management solution using wait/based performance analysis combined with
machine learning anomaly detection to pinpoint the root cause of performance
problems. This section will go through the highlights of DPA’s VM Option (add-on
feature to DPA) designed to bring in data from vSphere to make it easy for DBA’s to
determine how much of the virtualization layer has an impact, or not, on database
performance.
page 5
WHITEPAPER: VIRTUALIZED DATABASES: PERFORMANCE CONSIDERATIONS FOR DBAS

When the VM Option is included (via license key) with DPA, the primary homepage
shows a tab titled “VIRTUALIZATION” as seen below. Selecting this tab will result
in a view of only the database instances running in a VMware VM.

Figure 3 – DPA homepage with Virtualization tab selected

When the VM option is installed, new tabs appear on the primary SQL Total Wait
and Anomaly Detection page with VM Config as a new tab. VM and VM host data
are automatically included in all metrics views such as resources, and when drilling
down into a specific query.

Figure 4 – DPA trends and anomaly detection page with VM CONFIG tab visible

page 6
WHITEPAPER: VIRTUALIZED DATABASES: PERFORMANCE CONSIDERATIONS FOR DBAS

By selecting the “VM CONFIG” tab, data related to the virtual machine the specific
instance is running in is available including virtual CPUs (vCPU), virtual disk,
memory, etc. There are four additional tabs containing detailed data on the ESXI
host (server), the other VMs running on this host, along with virtual storage data and
physical host storage data. This gives the DBA insights into where their database
instance is running and the resources available to their database.

Figure 5 – The VM CONFIG tab provides a comprehensive view of the virtual infrastructure

While it’s nice for the DBA to see the overall virtual infrastructure supporting their
database instance, the value of integrated virtual monitoring and metrics comes
into play when looking at specific performance issues.

For example, when drilling into a specific query to find where the time is being
spent and to see recommendations from the tuning advisor, you’ll see when you
scroll down the page VM metrics are included with the analysis. These VM metrics
include CPU Ready, Co-Stop, and memory, which can be lined up with the database
metrics like executions, rows examined, blocking, and much more.

On top of these VM metrics being shown, DPA annotates VM events, so a DBA can
see if something like a vMotion or some other task occurred against their VM when
application performance degradation occurs.

page 7
WHITEPAPER: VIRTUALIZED DATABASES: PERFORMANCE CONSIDERATIONS FOR DBAS

Figure 6 – A rich set of VM metrics are including in the query drill down, including annotation of VM events

In addition to looking at detailed query analytics, the DPA RESOURCES tab includes
detailed host and VM metrics ranging from CPU and disk metrics to disk I/O and
network packets. Both OS and VM data are included in each resource section.

Figure 6 – A rich set of VM metrics are including in the query drill down, including annotation of VM events

Last but not least, the VM LAYERS tab provides a visual time slice of all database
metrics aligned with the database instance performance data, VM and OS,
physical host, and storage. This view gives DBAs the ability to instantly recognize
performance issues potentially tied to the VM—or not. The VM event annotation is
also included in this view.

page 8
WHITEPAPER: VIRTUALIZED DATABASES: PERFORMANCE CONSIDERATIONS FOR DBAS

Figure 8 – The VM layers tab gives an all-in-one view of a virtualized database instance

Summary
The complexity of the environments DBAs support continues to expand, not only
with virtualized databases but the growth of cloud hosted databases – DBaaS
(Database as a service). In addition to the virtualization data collected from the
SolarWinds THWACK survey, another important metric was collected—the ratio of
database instances per DBA managed.

While the database to DBA ratio was less than 1:25 for approximately half of the
respondents, the ratio was astounding for the other half.

• 12% were responsible for 26 – 50 database instances

• 3% were responsible for 51 – 100 database instances
• 9% were responsible for 100 – 150 database instances
• 3% were responsible for 150 – 200 database instances
• 8% were responsible for 200 or more database instances

The growing number of database instances along with supporting multiple

database platforms and virtualized infrastructure can make database performance
management a challenge for even the most senior DBA professional. Database
performance management and monitoring tools designed to provide single-
pane-of-glass views into database performance and to span multiple platforms,
virtualization, and cloud platforms are must-haves for over-burdened DBAs.

page 9
WHITEPAPER: VIRTUALIZED DATABASES: PERFORMANCE CONSIDERATIONS FOR DBAS

ABOUT SOLARWINDS
SolarWinds (NYSE:SWI) is a leading provider of powerful and affordable IT infrastructure
management software. Our products give organizations worldwide, regardless of type,
size, or IT infrastructure complexity, the power to monitor and manage the performance
of their IT environments, whether on-prem, in the cloud, or in hybrid models. We
continuously engage with all types of technology professionals—IT operations
professionals, DevOps professionals, and managed service providers (MSPs)—to
understand the challenges they face maintaining high-performing and highly available
IT infrastructures. The insights we gain from engaging with them, in places like our
THWACK online community, allow us to build products that solve well-understood IT
management challenges in ways that technology professionals want them solved. This
focus on the user and commitment to excellence in end-to-end hybrid IT performance
management has established SolarWinds as a worldwide leader in network management
software and MSP solutions. Learn more today at www.solarwinds.com.

For additional information, please contact SolarWinds at 866.530.8100 or email sales@solarwinds.com.

To locate an international reseller near you, visit http://www.solarwinds.com/partners/reseller_locator.aspx

© 2020 SolarWinds Worldwide, LLC. All rights reserved

The SolarWinds, SolarWinds & Design, Orion, and THWACK trademarks are the exclusive property of SolarWinds Worldwide, LLC or its affiliates,
are registered with the U.S. Patent and Trademark Office, and may be registered or pending registration in other countries. All other SolarWinds
trademarks, service marks, and logos may be common law marks or are registered or pending registration. All other trademarks mentioned
herein are used for identification purposes only and are trademarks of (and may be registered trademarks) of their respective companies.

This document may not be reproduced by any means nor modified, decompiled, disassembled, published or distributed, in whole or in part, or
translated to any electronic medium or other means without the prior written consent of SolarWinds. All right, title, and interest in and to the
software, services, and documentation are and shall remain the exclusive property of SolarWinds, its affiliates, and/or its respective licensors.

SOLARWINDS DISCLAIMS ALL WARRANTIES, CONDITIONS, OR OTHER TERMS, EXPRESS OR IMPLIED, STATUTORY OR OTHERWISE, ON
THE DOCUMENTATION, INCLUDING WITHOUT LIMITATION NONINFRINGEMENT, ACCURACY, COMPLETENESS, OR USEFULNESS OF
ANY INFORMATION CONTAINED HEREIN. IN NO EVENT SHALL SOLARWINDS, ITS SUPPLIERS, NOR ITS LICENSORS BE LIABLE FOR ANY
DAMAGES, WHETHER ARISING IN TORT, CONTRACT OR ANY OTHER LEGAL THEORY, EVEN IF SOLARWINDS HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES.