SQL Server and Hyper-V Dynamic Memory Part 3
In parts 1 and 2 of this series we looked at the basics of Hyper-V Dynamic Memory and SQL Server memory management. In this part Serdar looks at configuration guidelines for SQL Server memory management.
Update 8/2/11: please also refer to the recently published white paper: Running SQL Server with Hyper-V Dynamic Memory - Best Practices and Considerations.
Part 3: Configuration Guidelines for Hyper-V Dynamic Memory and SQL Server
Now that we understand SQL Server Memory Management and Hyper-V Dynamic Memory basics, let’s take a look at general configuration guidelines in order to utilize benefits of Hyper-V Dynamic Memory in your SQL Server VMs.
Requirements
Host Operating System Requirements
Hyper-V Dynamic Memory feature is introduced with Windows Server 2008 R2 SP1. Therefore in order to use Dynamic Memory for your virtual machines, you need to have Windows Server 2008 R2 SP1 or Microsoft Hyper-V Server 2008 R2 SP1 in your Hyper-V host.
Guest Operating System Requirements
In addition to this Dynamic Memory is only supported in Standard, Web, Enterprise and Datacenter editions of windows running inside VMs. Make sure that your VM is running one of these editions. For additional requirements on each operating system see “Dynamic Memory Configuration Guidelines” here.
SQL Server Requirements
All versions of SQL Server support Hyper-V Dynamic Memory. However, only certain editions of SQL Server are aware of dynamically changing system memory. To have a truly dynamic environment for your SQL Server VMs make sure that you are running one of the SQL Server editions listed below:
· SQL Server 2005 Enterprise
· SQL Server 2008 Enterprise / Datacenter Editions
· SQL Server 2008 R2 Enterprise / Datacenter Editions
Configuration guidelines for other versions of SQL Server are covered below in the FAQ section.
Guidelines for configuring Dynamic Memory Parameters
Here is how to configure Dynamic Memory for your SQL VMs in a nutshell:
Hyper-V Dynamic Memory Parameter |
Recommendation |
Startup RAM |
1 GB + SQL Min Server Memory |
Maximum RAM |
> SQL Max Server Memory |
Memory Buffer % |
5 |
Memory Weight |
Based on performance needs |
Startup RAM
In order to ensure that your SQL Server VMs can start correctly, ensure that Startup RAM is higher than configured SQL Min Server Memory for your VMs. Otherwise SQL Server service will need to do paging in order to start since it will not be able to see enough memory during startup.
Also note that Startup Memory will always be reserved for your VMs. This will guarantee a certain level of performance for your SQL Servers, however setting this too high will limit the consolidation benefits you’ll get out of your virtualization environment.
Maximum RAM
This one is obvious. If you’ve configured SQL Max Server Memory for your SQL Server, make sure that Dynamic Memory Maximum RAM configuration is higher than this value. Otherwise your SQL Server will not grow to memory values higher than the value configured for Dynamic Memory.
Memory Buffer %
Memory buffer configuration is used to provision file cache to virtual machines in order to improve performance. Due to the fact that SQL Server is managing its own buffer pool, Memory Buffer setting should be configured to the lowest value possible, 5%. Configuring a higher memory buffer will prevent low resource notifications from Windows Memory Manager and it will prevent reclaiming memory from SQL Server VMs.
Memory Weight
Memory weight configuration defines the importance of memory to a VM. Configure higher values for the VMs that have higher performance requirements. VMs with higher memory weight will have more memory under high memory pressure conditions on your host.
Questions and Answers
Q1 – Which SQL Server memory model is best for Dynamic Memory?
The best SQL Server model for Dynamic Memory is “Locked Page Memory Model”. This memory model ensures that SQL Server memory is never paged out and it’s also adaptive to dynamically changing memory in the system. This will be extremely useful when Dynamic Memory is attempting to remove memory from SQL Server VMs ensuring no SQL Server memory is paged out.
You can find instructions on configuring “Locked Page Memory Model” for your SQL Servers here.
Q2 – What about other SQL Server Editions, how should I configure Dynamic Memory for them?
Other editions of SQL Server do not adapt to dynamically changing environments. They will determine how much memory they should allocate during startup and don’t change this value afterwards. Therefore make sure that you configure a higher startup memory for your VM because that will be all the memory that SQL Server utilize
Tune Maximum Memory and Memory Buffer based on the other workloads running on the system. If there are no other workloads consider using Static Memory for these editions.
Q3 – What if I have multiple SQL Server instances in a VM?
Having multiple SQL Server instances in a VM is not a general recommendation for predictable performance, manageability and isolation. In order to achieve a predictable behavior make sure that you configure SQL Min Server Memory and SQL Max Server Memory for each instance in the VM. And make sure that:
· Dynamic Memory Startup Memory is greater than the sum of SQL Min Server Memory values for the instances in the VM
· Dynamic Memory Maximum Memory is greater than the sum of SQL Max Server Memory values for the instances in the VM
Q4 – I’m using Large Page Memory Model for my SQL Server. Can I still use Dynamic Memory?
The short answer is no. SQL Server does not dynamically change its memory size when configured with Large Page Memory Model. In virtualized environments Hyper-V provides large page support by default. Most of the time, Large Page Memory Model doesn’t bring any benefits to a SQL Server if it’s running in virtualized environments.
Q5 – How do I monitor SQL performance when I’m trying Dynamic Memory on my VMs?
Use the performance counters below to monitor memory performance for SQL Server:
Process - Working Set: This counter is available in the VM via process performance counters. It represents the actual amount of physical memory being used by SQL Server process in the VM.
SQL Server – Buffer Cache Hit Ratio: This counter is available in the VM via SQL Server counters. This represents the paging being done by SQL Server. A rate of 90% or higher is desirable.
Conclusion
These blog posts are a quick start to a story that will be developing more in the near future. We’re still continuing our testing and investigations to provide more detailed configuration guidelines with example performance numbers with a white paper in the upcoming months.
Now it’s time to give SQL Server and Hyper-V Dynamic Memory a try. Use this guidelines to kick-start your environment. See what you think about it and let us know of your experiences.
- Serdar Sutay