SQL Server 2014 e Dynamic Memory

Le considerazioni che farò in questo post sull’utilizzo della Dynamic Memory su VM che ospitano SQL Server non vale solo per la versione 2014, ma per tutte le versioni di SQL che la supportano ovvero per SQL Server 2005 e successivi. Infatti SQL Server 2005 è stata la prima versione di SQL Server in cui è stata introdotta la funzionalità Hot Add Memory.

Come specificato nella White Paper Running SQL Server with Hyper-V Dynamic Memory Best Practices and Considerations il vantaggio dell’utilizzo della Dynamic Memory per VM che ospitano SQL Server è essenzialmente quello della flessibilità dell’utilizzo della memoria evitando un’elevata assegnazione statica:

“One of the key benefits of leveraging dynamic memory is the flexibility to respond to the needs of a particular workload that would benefit from additional memory resources and make the most use out of all physical memory resources on a system.”

Ovviamente in scenari in cui è possibile un’assegnazione statica della memoria a SQL Server è possibile evitare l’utilizzo della Dynamic Memory, ma pensando a scenari in cui può verificarsi una Live Migration della VM che costringa un nodo di un cluster Hyper-V ad eseguire la VM insieme ad altre VM la Dynamic Memory può diventare essenziale ai fini della continuità di servizio.

Sempre basandosi sulle informazioni fornite nella White Paper Running SQL Server with Hyper-V Dynamic Memory Best Practices and Considerations è possibile configurare indicativamente come segue una VM Windows Server 2012 R2 dedicata a SQL Server 2014 per quanto riguarda la Dynamic Memory su un host Hyper-V con WS2012 R2:

  • Startup RAM 4096 MB (4 GB)
  • Minimum RAM 2048 MB (2 GB)
  • Maximum RAM 12288 MB (12 GB)

Inoltre si consiglia di impostare anche il valore massimo di memoria utilizzabile da SQL Server, da prove eseguite per SQL Server 2014 in ambiente Windows Server 2012 R2 ho rilevato che è consigliabile lasciare almeno 2GB al sistema operativo Guest se l’installazione di SQL Server non è di tipo Core, quindi nell’esempio di configurazione precedente impostare 10240 MB (10 GB = 12 GB – 2 GB). Valori più alti da prove eseguire hanno comportato problemi di avvio del SQL Agent e performance ridotte nella risposta di SQL Server alle query e nell’esecuzione della SQL Server Management Studio (per esempio Intellisense non funzionate).

Altre impostazioni suggerite sono l’impostazione dei diritti di Lock pages in memory all’account che esegue SQL Server (a riguardo si veda anche il mio post SQL Server gestione memoria e Pagefile).

Come indicato nel seguente Virtualizing SQL Server on Hyper-V and on Windows Azure VMs si tenga conto che l’utilizzo della Dynamic Memory implica l’impossibilità di utilizzare la funzionalità Virtual NUMA di Hyper-V come indicato in Hyper-V Virtual NUMA Overview:

“Note: Virtual NUMA and Dynamic Memory features cannot be used at the same time. Workloads that are not NUMA-aware will not take advantage of virtual NUMA.”

Di conseguenza se la VM dedicata a SQL Server è pensata per supportare alti carichi è meglio evitare di abilitare la Dynamic Memory, a riguardo si vedano le considerazioni in Hyper-V Virtual NUMA Overview e in particolare la seguente:

“When trying to decide which feature to use, you should take the following questions into consideration. If the answer to both is yes, enable virtual NUMA and do not enable Dynamic Memory.

  1. Is the workload running in the virtual machine NUMA-aware?
  2. Will the virtual machine consume more resources, processors, or memory than are available on a single physical NUMA node?”

Per quanto riguarda le impostazioni della VM di seguito i suggerimenti per la configurazione che è preferibile utilizzare come indicato in Virtualizing SQL Server on Hyper-V and on Windows Azure VMs:

  • VM Generation 2
  • Dischi virtuali VHDX
  • Impostazione dello Storage QoS nel caso si operi in uno scenario multi-tenant
  • Abilitare la Single-Root I/O Virtualization (SR-IOV) se l’host di virtualizzazione e le NIC lo supportano (per determinare se l’SR-IOV è supportato è possibile utilizzare i cmdlet PowerShell Get-VMHost | fl e Get-NetAdapterSriov a riguardo si veda Everything you wanted to know about SR-IOV in Hyper-V Part 8)
  • Utilizzare il NIC Teaming
  • Utilizzzare Receive Side Scaling (vRSS)
  • Utilizzare Dynamic Virtual Machine Queue (dVMQ)

Per ulteriori approfondimenti si vedano anche: