Database Reference
In-Depth Information
would cause the CPU Scheduler to migrate the world from a partial core to a full core is
not exceeded, the world will continue to be scheduled against the logical processor.
The second change in vSphere 5.0 is that the CPU Scheduler will take into account
when both logical processors are busy on a core; in previous versions of vSphere this
was not the case. The amount of time a world spends executing is tracked as CPU Time,
and the tracking of this is called “charging.” The amount of time charged for a world in
CPU Time is affected by execution against a partial core. As of vSphere 5.0, the amount
of time charged when both logical CPUs are busy is greater, which leads to the ability
of a vCPU that has fallen behind to catch up to its other vCPU partners in a more timely
fashion.
Note
To learn more about the CPU Scheduler and optimizations, we recommend
reading “The CPU Scheduler in VMware vSphere 5.1”
(
https://www.vmware.com/files/pdf/techpaper/VMware-vSphere-CPU-
Sched-Perf.pdf
).
So, what does all this mean for virtualizing SQL Server? It is important that the DBAs
and the vSphere administrators both understand whether HTT is enabled and in use. In
addition, it is important that performance be monitored on the system. Remember, the
Windows OS has no idea it is being virtualized, so when it sees it has been assigned 32
cores, it thinks these are full cores, although under the covers these vCPU worlds may
be executing against a logical core. HTT is good; it allows you to get more useful work
done and more performance out of SQL. Our recommendation is to use HTT. Just
remember to account for HTT when it comes to performance and sizing of the SQL
Server virtual machines on your ESXi hosts.
Memory Overcommitment
Next up on the memory train is a discussion of memory overcommitment. Earlier in this
chapter, we discussed vSphere's memory-reclamation techniques and our
recommendation to leave them enabled. When running SQL Servers on vSphere, it is
our recommendation to allow the SQL Servers time to bake, or run in production, on the
vSphere hosts. The baking time we recommend is at least one business cycle. This will
allow you to capture, via your monitoring tool, the performance peaks of the SQL
Server. There are some databases that sit dormant for 2.9 months a quarter, but when
they ramp up for that last week of the quarter, there better not be anything in their way or
else! This also where a tool like vCenter Operations Manager comes in handy because
