Il consumo di "Total Server Memory" di SQL Server è stagnante per mesi con 64 GB + in più disponibili

Ho riscontrato un problema strano in cui SQL Server 2016 Standard Edition 64-bit sembra aver superato la metà della memoria totale allocata (64 GB di 128 GB).

L'output di @@VERSIONè:

Microsoft SQL Server 2016 (SP1-CU7-GDR) (KB4057119) - 13.0.4466.4 (X64) 22 dic 2017 11:25:00 Copyright (c) Microsoft Corporation Standard Edition (64-bit) su Windows Server 2012 R2 Datacenter 6.3 ( Build 9600:) (Hypervisor)

L'output di sys.dm_os_process_memoryè:

Quando eseguo una query sys.dm_os_performance_counters, vedo che Target Server Memory (KB)è a 131072000ed Total Server Memory (KB)è poco meno della metà di quello a 65308016. Nella maggior parte degli scenari, comprenderei che si tratta di un comportamento normale poiché SQL Server non ha ancora stabilito che è necessario allocare ulteriore memoria per sé.

Tuttavia, è stato "bloccato" a ~ 64 GB per oltre 2 mesi. Durante questo lasso di tempo abbiamo eseguito una notevole quantità di operazioni ad alta intensità di memoria su alcuni database e abbiamo aggiunto all'istanza quasi altri 40 database. Siamo in totale 292 database, ciascuno con file di dati pre-allocati a 4 GB con una frequenza di crescita automatica di 256 MB e file di registro da 2 GB con una frequenza di crescita automatica di 128 MB. Eseguo un backup completo una volta ogni notte alle 12:00, e inizio i backup del registro delle transazioni dal lunedì al venerdì a partire dalle 6:00 alle 20:00 con un intervallo di ogni 15 minuti. Questi database sono relativamente bassi sul loro throughput complessivo, ma sono scettico sul fatto che qualcosa non funzioni, dato che SQL Server non si è avvicinatoTarget Server Memory naturalmente attraverso nuove aggiunte di database, normali esecuzioni di query, nonché pipeline ETL ad alta intensità di memoria che sono state eseguite.

L'istanza stessa di SQL Server si trova su un server Windows Server 2012R2 virtualizzato (VMware) con 12 CPU, 144 GB di memoria (da 128 GB a SQL Server, 16 GB riservati per Windows) e 4 dischi virtuali totali che si trovano su un vSAN con unità SAS da 15 KB . Windows si trova naturalmente su un disco C: 64 GB con un file di paging di 32 GB. I file di dati si trovano su un disco D: 2 TB, i file di registro si trovano su un disco L: 2 TB e tempdb si trova su un disco T: 256 GB con file 8x16 GB senza autogrowth.

Ho verificato che non ci sono altre istanze di SQL Server in esecuzione sul server oltre MSSQLSERVER.

Questo server è interamente dedicato solo all'istanza di SQL Server, quindi non abbiamo altre applicazioni o servizi in esecuzione che potrebbero consumare memoria.

Uso RedGate SQL Monitor per l'analisi e di seguito è riportata una cronologia degli ultimi 18 giorni di Total Server Memory. Come puoi vedere, l'utilizzo della memoria è rimasto del tutto stagnante a parte un singolo aumento di ~ 300 MB all'inizio di aprile.

Quale potrebbe essere la causa di questo? Cosa posso dare un'occhiata più da vicino per determinare perché SQL Server non vuole utilizzare i 64 GB + di memoria aggiuntiva allocati?

L'output di esecuzione sp_Blitz:

sp_Blitz @OutputType = 'markdown', @CheckServerInfo = 1;

Priorità 50: Prestazioni :

• Scheduler della CPU offline: alcuni core della CPU non sono accessibili a SQL Server a causa di mascheramenti di affinità o problemi di licenza.

• Nodi di memoria offline: a causa di mascheramenti di affinità o problemi di licenza, parte della memoria potrebbe non essere disponibile.

Priorità 50: Affidabilità :

• DAC remoto disabilitato - L'accesso remoto a Dedicated Admin Connection (DAC) non è abilitato. Il DAC può semplificare molto la risoluzione dei problemi in remoto quando SQL Server non risponde.

Priorità 100: Prestazioni :

• Molti piani per una query - 300 piani sono presenti per una singola query nella cache del piano - il che significa che probabilmente abbiamo problemi di parametrizzazione.

• Trigger del server abilitati

  • Il trigger del server [RG_SQLLighthouse_DDLTrigger] è abilitato. Assicurati di capire cosa sta facendo quel trigger: meno lavoro fa, meglio è.

  • Il trigger del server [SSMSRemoteBlock] è abilitato. Assicurati di capire cosa sta facendo quel trigger: meno lavoro fa, meglio è.

Priorità 150: Prestazioni :

• Query che richiedono suggerimenti di join: dal riavvio sono state registrate 1480 istanze di suggerimenti di join. Ciò significa che le query stanno guidando l'ottimizzatore di SQL Server e, se non sanno cosa stanno facendo, ciò può causare più danni che benefici. Questo può anche spiegare perché gli sforzi di ottimizzazione DBA non funzionano.

• Suggerimenti per forzare l'ordine - 2153 istanze di suggerimento dell'ordine sono state registrate dal riavvio. Ciò significa che le query stanno guidando l'ottimizzatore di SQL Server e, se non sanno cosa stanno facendo, ciò può causare più danni che benefici. Questo può anche spiegare perché gli sforzi di ottimizzazione DBA non funzionano.

Priorità 170: Configurazione file :

• Database di sistema sull'unità C.

  • master: il database master ha un file nell'unità C. L'inserimento di database di sistema nell'unità C comporta il rischio di arresti anomali del server quando si esaurisce lo spazio.

  • modello: il database del modello ha un file sull'unità C. L'inserimento di database di sistema nell'unità C comporta il rischio di arresti anomali del server quando si esaurisce lo spazio.

  • msdb - Il database msdb ha un file sull'unità C. L'inserimento di database di sistema nell'unità C comporta il rischio di arresti anomali del server quando si esaurisce lo spazio.

Priorità 200: informativo :

• Processi dell'agente che si avviano contemporaneamente: più lavori dell'agente SQL Server sono configurati per l'avvio simultaneo. Per elenchi di pianificazione dettagliati, vedere la query nell'URL.

• Tabelle nel master del database master: la tabella CommandLog nel database master è stata creata dagli utenti finali il 30 luglio 2017 alle 17:22. Le tabelle nel database principale potrebbero non essere ripristinate in caso di emergenza.

• TraceFlag On

  • Il flag di traccia 1118 è abilitato a livello globale.

  • Il flag di traccia 1222 è abilitato a livello globale.

  • Il flag di traccia 2371 è abilitato a livello globale.

Priorità 200: Configurazione server non predefinita :

• Agent XPs: questa opzione sp_configure è stata modificata. Il suo valore predefinito è 0 ed è stato impostato su 1.

• backup checksum default - Questa opzione sp_configure è stata modificata. Il suo valore predefinito è 0 ed è stato impostato su 1.

• impostazione predefinita di compressione backup: questa opzione sp_configure è stata modificata. Il suo valore predefinito è 0 ed è stato impostato su 1.

• soglia di costo per il parallelismo: questa opzione sp_configure è stata modificata. Il suo valore predefinito è 5 ed è stato impostato su 48.

• massimo grado di parallelismo: questa opzione sp_configure è stata modificata. Il suo valore predefinito è 0 ed è stato impostato su 12.

• max server memory (MB) - Questa opzione sp_configure è stata modificata. Il suo valore predefinito è 2147483647 ed è stato impostato su 128000.

• ottimizza per carichi di lavoro ad hoc: questa opzione sp_configure è stata modificata. Il suo valore predefinito è 0 ed è stato impostato su 1.

• mostra opzioni avanzate: questa opzione sp_configure è stata modificata. Il suo valore predefinito è 0 ed è stato impostato su 1.

• xp_cmdshell - Questa opzione sp_configure è stata modificata. Il suo valore predefinito è 0 ed è stato impostato su 1.

Priorità 200: affidabilità :

• Stored procedure estese in Master

• master - La stored procedure estesa [sqbdata] si trova nel database master. CLR potrebbe essere in uso e il database master ora deve essere parte della pianificazione del backup / ripristino.

  • master - La stored procedure estesa [sqbdir] si trova nel database master. CLR potrebbe essere in uso e il database master ora deve essere parte della pianificazione del backup / ripristino.

  • master - La stored procedure estesa [sqbmemory] si trova nel database master. CLR potrebbe essere in uso e il database master ora deve essere parte della pianificazione del backup / ripristino.

  • master - La stored procedure estesa [sqbstatus] si trova nel database master. CLR potrebbe essere in uso e il database master ora deve essere parte della pianificazione del backup / ripristino.

  • master - La stored procedure estesa [sqbtest] si trova nel database master. CLR potrebbe essere in uso e il database master ora deve essere parte della pianificazione del backup / ripristino.

  • master: la stored procedure estesa [sqbtestcancel] si trova nel database master. CLR potrebbe essere in uso e il database master ora deve essere parte della pianificazione del backup / ripristino.

  • master: la stored procedure estesa [sqbteststatus] si trova nel database master. CLR potrebbe essere in uso e il database master ora deve essere parte della pianificazione del backup / ripristino.

  • master - La stored procedure estesa [sqbutility] si trova nel database master. CLR potrebbe essere in uso e il database master ora deve essere parte della pianificazione del backup / ripristino.

  • master - La stored procedure estesa [sqlbackup] si trova nel database master. CLR potrebbe essere in uso e il database master ora deve essere parte della pianificazione del backup / ripristino.

Priorità 210: Configurazione database non predefinita :

• Lettura isolamento snapshot abilitato abilitato: questa impostazione del database non è l'impostazione predefinita.

  • Redgate

  • RedGateMonitor

• Isolamento snapshot abilitato: questa impostazione del database non è quella predefinita.

  • Redgate

  • RedGateMonitor

Priorità 240: attendere le statistiche :

• 1 - SOS_SCHEDULER_YIELD - 1770,8 ore di attesa, 115,9 minuti tempo di attesa medio all'ora, 100,0% di attesa del segnale, 1419212079 attività di attesa, 4,5 ms tempo di attesa medio.

Priorità 250: informativo :

• SQL Server è in esecuzione con un account del servizio NT, sto eseguendo come servizio NT \ MSSQLSERVER. Vorrei invece avere un account di servizio di Active Directory.

Priorità 250: Informazioni sul server :

• Contenuto della traccia predefinita: la traccia predefinita contiene 36 ore di dati tra il 14 aprile 2018 23:21 e il 16 aprile 2018 11:13. I file di traccia predefiniti si trovano in: C: \ Programmi \ Microsoft SQL Server \ MSSQL13.MSSQLSERVER \ MSSQL \ Log

• Drive C Space - 196816.00MB gratuiti su unità C.

• Drive D Space - 894823.00MB gratuito su E drive

• Drive L Space - 1361367.00MB gratis su F drive

• Drive T Space - 114441.00MB gratuiti su G drive

• Hardware - Processori logici: 12. Memoria fisica: 144 GB.

• Hardware - Config. NUMA

  • Nodo: 0 Stato: ONLINE Programmatori online: 4 Programmatori offline: 2 Gruppo processore: 0 Nodo memoria: 0 Memoria VAS GB riservato: 186

  • Nodo: 1 Stato: OFFLINE Programmatori online: 0 Programmatori offline: 6 Gruppo processore: 0 Nodo memoria: 0 Memoria VAS GB riservato: 186

• Inizializzazione file istantanea abilitata: l'account del servizio dispone dell'autorizzazione Esegui attività di manutenzione volume.

• Piano di alimentazione - Il tuo server ha CPU a 2,60 GHz ed è in modalità di alimentazione bilanciata - Uh ... vuoi che le tue CPU funzionino alla massima velocità, giusto?

• Ultimo riavvio del server - 9 marzo 2018 7:27

• Nome server - [redatto]

• Servizi

  • Servizio: SQL Server (MSSQLSERVER) viene eseguito con l'account di servizio NT Service \ MSSQLSERVER. Ultimo orario di avvio: 9 marzo 2018 7:27. Tipo di avvio: automatico, attualmente in esecuzione.

  • Servizio: SQL Server Agent (MSSQLSERVER) viene eseguito con l'account di servizio LocalSystem. Ultimo tempo di avvio: non mostrato. Tipo di avvio: automatico, attualmente in esecuzione.

• Ultimo riavvio di SQL Server - 9 marzo 2018 6:27

• Servizio SQL Server - Versione: 13.0.4466.4. Livello di patch: SP1. Aggiornamento cumulativo: CU7. Edizione: Standard Edition (64-bit). Gruppi di disponibilità abilitati: 0. Stato gestore gruppi di disponibilità: 2

• Server virtuale - Tipo: (HYPERVISOR)

• Versione di Windows: stai eseguendo una versione piuttosto moderna di Windows: Server 2012R2 era, versione 6.3

Priorità 254: Rundate :

• Diario del capitano: stardare qualcosa e qualcosa ...

Scommetto che hai configurato le CPU virtuali in modo che alcuni dei nodi della CPU e / o dei nodi di memoria siano offline.

Scarica sp_Blitz (disclaimer: sono uno degli autori di quello script open source gratuito) ed eseguilo :

sp_Blitz @CheckServerInfo = 1;

Cercare avvisi sulla CPU e / o sui nodi di memoria non in linea. SQL Server Standard Edition vede solo i primi 4 socket CPU e potresti aver configurato la VM come qualcosa di simile a 6 CPU dual-core. Finirà per colpire un problema simile a come i limiti di 20 core di Enterprise Edition limitano la quantità di memoria che puoi vedere .

Se vuoi condividere l'output di sp_Blitz qui, puoi eseguirlo in questo modo per l'output in Markdown, che puoi quindi copiare / incollare nella tua domanda:

sp_Blitz @OutputType = 'markdown', @CheckServerInfo = 1;

Aggiornamento 2018/04/16 - confermato. Hai collegato l'output di sp_Blitz (grazie per quello!) E dimostra che hai offline CPU e nodi di memoria. Chiunque abbia creato la VM l'ha configurata come 12 CPU single-core, quindi SQL Server Standard Edition vede solo i primi 4 socket (core) e la memoria ad essi collegata.

Per risolvere il problema, arrestare la VM, configurarla come una VM a 2 socket e 6 core, quindi SQL Server Standard Edition vedrà tutti i core e la memoria. Ciò ridurrà anche le tue attese SOS_SCHEDULER_YIELD: proprio ora, il tuo SQL Server sta martellando i primi 4 core, ma è tutto. Dopo questa correzione, sarà in grado di funzionare su tutti e 12 i core.

Come addendum al piano d'azione di Brent Ozar , volevo condividere i risultati. Come notato da Brent, all'interno di VMware avevamo configurato la macchina virtuale in modo errato con 12 CPU single-core. Ciò ha comportato che gli 8 core rimanenti fossero inaccessibili da SQL Server e, di conseguenza, ha portato al problema di memoria descritto nella mia domanda originale. La scorsa notte abbiamo messo i nostri servizi in modalità di manutenzione per riconfigurare la VM in modo appropriato. Non solo stiamo vedendo la memoria insinuarsi in modo normale, ma come ha anche suggerito Brent, il numero di attese è diminuito in modo esponenziale e le nostre prestazioni complessive di SQL Server sono salite alle stelle. Le configurazioni di vNUMA ora sono piccoli componenti felici che tagliano i nostri carichi di lavoro.

Per quelli che potrebbero utilizzare VMware vSphere 6.5, i brevi passaggi per completare l'elemento dell'azione descritto da Brent sono i seguenti.

1. Accedere al client Web vSphere per il cluster VMware e accedere alla macchina virtuale che ospita SQL Server. La VM deve essere offline per regolare le configurazioni della CPU e della memoria.

2. Nel riquadro principale, vai a Configure > VM hardware, fai clic sul Editpulsante nell'angolo in alto a destra. Si aprirà un menu di scelta rapida che ha Edit Settings. Per riferimento, l'immagine sotto è la configurazione errata . Si noti che ho Cores per Socketimpostato su 1. Date le limitazioni di SQL Server Standard Edition, questa è una configurazione errata.

   

3. La correzione è semplice come regolare il Cores per Socketvalore. Nel nostro caso, lo impostiamo in 6modo che abbiamo 2 Sockets. Ciò consente a SQL Server di utilizzare tutti e 12 i processori.

   

Una nota importante: non impostare il valore su dove o Number of Coreso Socketssarebbe un numero dispari. NUMA ama l'equilibrio, e per regola empirica, deve essere divisibile per 2. Ad esempio, una configurazione da 4 core a 3 socket sarebbe sbilanciata. In effetti, se dovessi eseguire sp_Blitzquesto tipo di configurazione, si darebbe un avvertimento al riguardo.

La sezione 3.3 in Architecting Microsoft SQL Server su VMware vSphere (avviso PDF) lo descrive in dettaglio. Le pratiche descritte nel white paper sono applicabili alla maggior parte della virtualizzazione locale di SQL Server.

Ecco alcune altre risorse che ho compilato attraverso la mia ricerca dopo il post di Brent:

• Virtualizzazione di database di grandi dimensioni - Pianificazione della capacità della CPU VMware

• Virtual Machine vCPU e vNUMA Rightsizing - Regole empiriche

• Disaccoppiamento dei core per socket dalla topologia NUMA virtuale in vSphere 6.5

Finirò con un'acquisizione da RedGate SQL Monitor nelle ultime 24 ore. Il punto principale da notare è l'utilizzo della CPU e il numero di attese: durante le nostre ore di punta ieri, abbiamo riscontrato un uso intenso della CPU e abbiamo aspettato contese. Dopo questa semplice correzione, abbiamo migliorato di dieci volte le nostre prestazioni. Anche il nostro I / O su disco si è ridotto in modo significativo. Questa è un'impostazione apparentemente facilmente trascurata che può migliorare le prestazioni virtuali di un ordine di grandezza. Almeno, è stato trascurato dai nostri ingegneri e un momento completo d'oh .

Inoltre, secondo MSDN , lo standard SQL Server è limitato a 64 GB di RAM. Abbiamo risolto questo problema suddividendo il database in più istanze, ma la tua situazione potrebbe non consentirlo.

Hmm 2016 sembra avere un limite di 128 GB, ma la divisione dell'istanza potrebbe essere ancora un'opzione.