Databases Reference
In-Depth Information
➤
Busy
server workloads need planning. The latest hypervisors claim to be able to accommodate
them, but you need to design and tune your environment well i rst, in order to ensure the
success promised by your virtualization vendor's marketing. These workloads rel ect those
servers that you already have to proactively manage, even on relatively new server hardware.
In the database world, these are likely to be transactional systems that have a high throughput
of order or quotes being processed, or perhaps reporting servers that routinely perform
CPU-intensive server-side aggregations. These are demanding workloads that require
thorough planning and testing before deploying in a virtual environment.
Gathering Sizing Data
So far we've approached the identii cation of “good” virtualization candidates fairly unscientii cally,
whereas some virtualization specialists I've worked with would have immediately started collecting
performance data and analyzing it. That step is still crucial for your virtualization planning, but
working through the guiding principles just described should only take a couple of moments, and
it will help you to quickly identify your potential risks and concerns, or even nonstarters, and save
you some time.
More detail is provided in the next section on how to use collected coni guration, utilization, or
performance data to help design a virtual server running SQL Server successfully, but the following
list describes some data you should collect and explains why it will be useful to your planning:
➤
Memory utilization
— This is one of the most important, if not the most important, piece of
performance data to capture. How much memory does your database server currently have
installed, how much does SQL Server currently actually use, and does SQL Server even
have sufi cient memory right now?
Some of the counters available in Performance Monitor you can use here are probably
what you already use today for monitoring SQL Server. An instance with a very high
(25,000
1
seconds) Page Life Expectancy is likely to be able to be virtualized with the same
or perhaps less memory than it has currently without signii cantly affecting performance.
However, if there is a very low Page Life Expectancy value consistently being seen
(<1,000 seconds) then it's likely the server already has insufi cient memory and I would
expect the server when virtualized to have more memory than it has now. Finally, the Total
and Target Server Memory counter values should also be used to determine what amount of
memory is too much or too little based on the current Page Life Expectancy; it may be that
not all of the server's memory is being made available for SQL Server to use.
➤
CPU utilization
— This data will help you understand the server's workload patterns and
identify how easy it will be for your server to coexist with other virtual servers on the same
host server once virtualized. As well as collecting the Average Total CPU utilization, you
should also monitor how often periods of high activity occur and how long they last. For
example, you might run a recalculation job every hour that takes 10 minutes to run. In
addition to collecting CPU utilization data from within Performance Monitor, you should
also understand how your instance of SQL Server uses parallelism. While your current
physical server might have 16 cores, running a smaller number of parallelized queries on it
requires different planning than if you run a much larger number of serial queries.
Search WWH ::
Custom Search