Risoluzione dei problemi relativi alle prestazioni della CPU di SQL Server

Questo articolo tratterà ciascuno di questi passaggi. Darò per scontato che potresti non utilizzare uno strumento di monitoraggio di terze parti. Se lo sei, il framework qui si applica ancora, ma le fonti di dati e gli strumenti a tua disposizione variano da quello che descrivo.

Definisci il problema

Per prima cosa dobbiamo esaminare il problema. Quando qualcuno viene da te e dice che sta riscontrando un problema di prestazioni della CPU, questo potrebbe significare un numero qualsiasi di cose diverse. Quindi il primo compito è capire quale sia attualmente la natura del problema relativo alle prestazioni della CPU.

Alcune categorie comuni includono:

• La disponibilità è stata influenzata a causa di "CPU ancorate". Ad esempio, tutti gli scheduler funzionano al 100% su tutta la linea e il throughput è bloccato o notevolmente ridotto.
• Degrado delle prestazioni dovuto all'utilizzo della CPU "superiore al normale". Quindi non siamo ancorati, ma le tue CPU funzionano a una percentuale più alta del normale e presumibilmente ciò incide sulle prestazioni.
• Un'altra categoria comune di problemi di prestazioni della CPU è lo scenario "vincitori e perdenti" in cui i carichi di lavoro sono in competizione tra loro. Forse hai un carico di lavoro OLTP che sta riscontrando una velocità effettiva ridotta a causa di una query di report in esecuzione parallela.
• Un altro problema potrebbe essere l'incontro di un punto critico, in cui le limitazioni di capacità e scalabilità complessive del tuo sistema vengono colpite a un certo punto.

Cito queste categorie generali come punto di partenza, ma so che spesso possono esserci forti dipendenze su questi problemi e una categorizzazione può fondersi nell'altra. Detto questo, il primo passo è definire i sintomi e i problemi il più chiaramente possibile.

Convalida le condizioni attuali

Indipendentemente dal fatto che il problema si sia verificato in passato o si stia verificando in questo momento, è importante ottenere quante più informazioni di base possibili sul sistema, sul carico di lavoro e sulle configurazioni. Se stai utilizzando linee di base e runbook, idealmente stai già tracciando gran parte di queste informazioni. In caso contrario, chiediti quanto velocemente potresti ottenere risposte a queste domande alle 2 del mattino nel mezzo di una crisi.

Le seguenti sottosezioni trattano dati importanti che in genere mi interessano per un problema di prestazioni della CPU.

Dettagli fisici del server

• Quanti socket e core?
• L'hyper-threading è abilitato?
• Qual ​​è il modello di processore, l'architettura (32 bit/64 bit)?

Dettagli del server virtuale

• Si tratta di un ospite virtuale?
• Se è così, ora sarai interessato anche ai dettagli sull'host e sugli altri ospiti virtuali con cui condividi le risorse.
• Ci sono impostazioni relative alla CPU attive?
• Ad esempio, CPU Hyper-V

Riserva, prenotazione CPU VMware, peso relativo CPU Hyper-V e condivisioni CPU VMware.

• Quante vCPU sono allocate tra i guest?
• Quante vCPU ha questo guest?
• L'ospite è stato migrato di recente a un nuovo host prima del problema?

Impostazioni di configurazione dell'istanza di SQL Server

• Impostazione del grado massimo di parallelismo
• Soglia di costo per l'opzione di parallelismo
• Impostazione dell'affinità del processore
• Impostazione di aumento della priorità
• Impostazione numero massimo di thread di lavoro
• Impostazione di pooling leggera


Le prime tre configurazioni potrebbero richiedere ulteriori discussioni. Raramente ci sono valori assoluti riguardo a queste impostazioni.

Per quanto riguarda le ultime tre impostazioni, come "aumento della priorità", se vedo che sono su valori non predefiniti spingerò sicuramente per ulteriori informazioni di base e cronologia.

Impostazioni opzione alimentazione CPU

• Qual ​​è l'impostazione dell'opzione di alimentazione? (Livello del sistema operativo, host di macchine virtuali o controllato dal BIOS)
  • Alte prestazioni, bilanciato, risparmio energetico?

Le impostazioni dell'opzione di alimentazione al di sotto di "Prestazioni elevate" sono ancora molto comuni e non devono essere ignorate per i server che ospitano istanze di SQL Server.

Configurazione del governatore delle risorse

• È configurato oltre le impostazioni predefinite?


Trovo ancora che sia raro incontrare clienti che utilizzano questa funzione, ma è facile verificare se viene utilizzata e ne varrà la pena per le volte in cui è effettivamente configurata oltre l'impostazione predefinita.

Registro degli errori di SQL Server e registri degli eventi di Windows

• Vedi avvisi o errori insoliti?


Perché cercare nei registri degli errori e degli eventi un problema con la CPU? A volte i problemi a monte possono causare problemi di prestazioni a valle in SQL Server. Non vuoi perdere tempo a ottimizzare una query o aggiungere un nuovo indice quando sei a monte, il problema principale è un problema di degrado dei componenti hardware.

Rispondi "È SQL Server?"

Sembra ovvio quando lo chiedo, ma non vuoi davvero dedicare molto tempo alla risoluzione di un problema elevato della CPU in SQL Server se il colpevole non è effettivamente SQL Server.

Invece, prenditi un momento per controllare quale processo sta consumando più CPU. Ci sono diverse opzioni tra cui scegliere, tra cui:

• Processo:% tempo utente (modalità utente)
• Processo:% tempo privilegiato (modalità kernel)
• Gestione attività
• Esplora processo
• Informazioni recenti sulla CPU tramite sys.dm_os_ring_buffers o la sessione di integrità del sistema per le istanze specifiche di SQL Server in esecuzione sul sistema

Se si tratta di SQL Server e disponi di più istanze di SQL Server tra cui scegliere, assicurati di risolvere i problemi relativi all'istanza di SQL Server corretta sull'host. Ci sono alcuni modi per farlo, incluso l'uso di SELECT SERVERPROPERTY('processid') per ottenere il PID e quindi associarlo a Task Manager o Process Explorer.
Dopo aver confermato che si tratta di SQL Server, stai riscontrando un tempo utente elevato o un tempo privilegiato (kernel)? Anche in questo caso è possibile confermare tramite Process:% Privileged Time (oggetto sqlservr) e anche Task Manager di Windows o Process Explorer.

Sebbene i problemi di tempo del kernel elevati dovrebbero essere rari, richiedono comunque percorsi di risoluzione dei problemi diversi rispetto ai problemi di risoluzione dei problemi della CPU del tempo utente standard. Alcune potenziali cause di tempi lunghi del kernel includono driver di filtro difettosi (antivirus, servizi di crittografia), aggiornamenti firmware e driver non aggiornati o mancanti o componenti I/O difettosi.

Identifica i consumatori della CPU

Dopo aver convalidato quale istanza di SQL Server sta guidando l'utilizzo della CPU in tempo utente sul sistema, sul Web sono disponibili numerosi esempi di query predefiniti che è possibile utilizzare.

Di seguito è riportato un elenco di DMV che le persone usano comunemente in varie forme durante un problema di prestazioni. Ho strutturato questo in un formato di domande e risposte per aiutare a inquadrare il motivo per cui vorresti accedervi.

Quali richieste sono in esecuzione in questo momento e qual è il loro stato?

• sys.dm_exec_requests

Che cosa sta eseguendo?

• sys.dm_exec_sql_text

Da dove viene?

• sys.dm_exec_sessions
• sys.dm_exec_connections

Qual ​​è il suo piano stimato? (ma fai attenzione a distruggere xml su un sistema già vincolato dalla CPU)

• sys.dm_exec_query_plan

Chi sta aspettando una risorsa e cosa sta aspettando?

• sys.dm_os_waiting_tasks

Quali query hanno richiesto più tempo di CPU dall'ultimo riavvio?

• sys.dm_exec_query_stats
• Aggrega per total_worker_time
• Definisci le medie con count_esecuzione
• Se carichi di lavoro ad hoc, puoi raggruppare per query_hash
• Usa plan_handle con sys.dm_exec_query_plan per prendere il piano

Questa query utilizza il parallelismo?

• sys.dm_os_tasks
  • Ordinato per session_id, request_id
• sys.dm_exec_query_plan
  • Guarda gli operatori del piano, ma tieni presente che questo è solo il piano stimato
• sys.dm_exec_query_stats
  • Filtra total_elapsed_time inferiore a total_worker_time
  • Ma nota che questo può essere un falso negativo per bloccare gli scenari, in cui la durata è gonfiata a causa di un'attesa sulla risorsa

Abbina lo schema e risolvi

Probabilmente stai ridendo di questo particolare passaggio, poiché questo può essere il più coinvolto (ed è un altro motivo per cui i professionisti di SQL Server sono impiegati in modo remunerativo). Esistono diversi modelli e risoluzioni associate, quindi finirò questo post con un elenco dei driver più comuni per problemi di prestazioni della CPU che ho visto negli ultimi anni:

• Operazioni I/O elevate (e nella mia esperienza questo è il driver più comune della CPU)
• Problemi con la stima della cardinalità (e associata scarsa qualità del piano di query)
• Parallelismo imprevisto
• Compilazione/ricompilazione eccessiva
• Chiamate UDF ad alta intensità di calcolo, operazioni di distruzione
• Operazioni riga per riga agonizzante
• Attività di manutenzione simultanee (ad es. AGGIORNAMENTO delle statistiche con FULLSCAN)

Ogni area che ho identificato ha un ampio corpo di lavoro associato da ricercare. In termini di risorse consolidate, penso ancora che una delle migliori sia ancora l'articolo tecnico "Troubleshooting Performance Problems in SQL Server 2008" scritto da Sunil Agarwal, Boris Baryshnikov, Keith Elmore, Juergen Thomas, Kun Cheng e Burzin Patel.

Riepilogo

Come con qualsiasi metodologia, ci sono limiti per il suo utilizzo e aree in cui sei giustificato nell'improvvisare. Tieni presente che non sto suggerendo che i passaggi che ho descritto in questo post vengano utilizzati come una struttura rigida, ma consideralo invece un punto di partenza per i tuoi sforzi di risoluzione dei problemi. Anche i professionisti di SQL Server più esperti possono commettere errori da principiante o essere influenzati dalle loro esperienze di risoluzione dei problemi più recenti, quindi avere una metodologia minima può aiutare a evitare la risoluzione del problema sbagliato.