Există mai multe tactici pentru a determina ce cauzează cel mai adesea așteptările SQL Server, astfel încât să puteți înțelege de unde să optimizați performanța.
Glenn Berry, Louis Davidson și Tim Ford,
- DMO wait_stats va arăta ce evenimente sunt în așteptare pentru firele de sistem care sunt legate de SQL Server.
- performance_counters va arăta valoarea contoarelor de performanță SQL Server și modul de interpretare a acestora.
- ring_buffers, schedulers și wait_stats vă vor anunța problemele legate de utilizarea procesorului.
- sys_info va afișa caracteristicile computerului pe care rulează serverul dvs. SQL.
- sys_memory și process_memory vor arăta modul în care este utilizată memoria ca întreg.
- memory_cache_counters sau descriptorii tampon vor arăta modul în care se utilizează memoria cache.
Expectări SQL Server
În aceeași privință, sunt afișate contoarele de performanță (PerfMon), care oferă informații specifice despre utilizarea resurselor (rata de transfer a datelor de pe discuri, timpul utilizat de CPU etc.). Comparând statisticile așteptărilor cu măsurătorile privind consumul de resurse, puteți găsi rapid resursele sistemului cu cea mai mare concurență și identificați posibilele blocaje.
Așteptările și coada de așteptare
Sarcina planificatorului este distribuirea uniformă a sarcinii între fluxurile de lucru disponibile. Dacă fluxul de lucru al sesiunii este executat de către procesor, starea sesiunii (afișată în coloana Starea din sys.dm_exec_requests) este Rularea.
Dacă firul este pregătit pentru execuție, dar planificatorul la care este alocat execută în prezent o altă sesiune, firul este plasat într-o coadă de thread gata de rulare (runnable). Acest lucru înseamnă pur și simplu că este în coada de așteptare pentru accesul la procesor. Aceasta se numește o așteptare a semnalului.
Așteptând semnalul
Timpul de așteptare a semnalului este afișat în coloana signal_wait_time_ms. Aceasta reflectă numai timpul de așteptare al procesorului. Dacă sesiunea așteaptă să fie disponibilă o altă resursă, cum ar fi o pagină blocată, sau dacă executabilul trebuie să efectueze I / O, se trece la lista de așteptare. Aceasta este așteptarea resurselor, iar starea unei astfel de sesiuni de așteptare este amintită ca fiind "suspendată". Motivul așteptării este stocat și afișat în coloana wait_type a sys.dm_os_wait_stats DMV.
Timpul total de așteptare este afișat în coloana wait_time_ms, astfel încât să puteți calcula timpul de așteptare al resursei după cum urmează:
Așteptare pentru resurse = Timp total de așteptare - Timp de așteptare a semnalelor (Sau (wait_time_ms) - (signal_wait_time_ms))
Așteptarea semnalelor este inevitabilă în sistemele OLTP (procesarea tranzacțiilor online), deoarece implică un număr mare de tranzacții scurte. Un indicator cheie care descrie sarcina potențială a procesorului este procentajul pe care timpul de așteptare pentru semnale este de la timpul total de așteptare.
Un procent mare înseamnă că procesorul este încărcat. Adesea, "procentul mai mare" se înțelege mai mult de 25%, însă depinde de sistemul dvs. Valori mai mari de 10-15% sunt motive de îngrijorare. În general, statisticile privind așteptările reprezintă un instrument excelent pentru diagnosticarea timpului de răspuns al sistemului dvs. Cu cuvinte simple, fie lucrați, fie așteptați.
Dacă timpul de răspuns este prea lung și observați că așteptarea nu durează mult sau că așteptați semnalul, trebuie să vă concentrați asupra procesorului. Dacă observați că timpul de răspuns constă în principal în așteptarea altor resurse (cum ar fi rețeaua, I / O, etc.), trebuie să vă concentrați asupra optimizării utilizării acestor resurse.
Profilarea pentru optimizarea performanțelor
Această interogare simplă calculează procentul care reprezintă timpul de așteptare al semnalelor și timpul de așteptare al resurselor din timpul total de așteptare pentru a diagnostica încărcarea potențială a procesorului:
Dacă instanța dvs. de server SQL rulează destul de mult și ați făcut o schimbare semnificativă, de exemplu, ați adăugat un nou index important, trebuie să luați în considerare ștergerea vechilor statistici. În caz contrar, statisticile vechi acumulate vor ascunde efectul schimbării dvs. asupra timpului de așteptare.
Cel de-al doilea script de exemplu (Figura 1) arată cum se utilizează sys.dm_os_wait_stats DMV pentru a determina resursele pe care SQL Server le petrece cel mai mult timp.
Fig. 1. Acest scenariu generează un raport privind principalele cauze ale așteptărilor
Scenariul din Fig. 1 vă permite să găsiți cele mai importante blocaje la nivelul instanței. Acest lucru vă permite să concentrați eforturile de optimizare asupra anumitor tipuri de probleme. De exemplu, dacă, conform statisticilor acumulate, primul loc este ocupat de așteptările asociate cu discul I / O, ar trebui să investigați în continuare această problemă utilizând solicitările DMV și contoarele PerfMon legate de discuri.
Calculatoare de performanță
DMV, care prezintă datele contoarelor PerfMon, este sys.dm_os_performance_counters. Se întoarce după înregistrare pentru fiecare contor de performanță suportat de server. Acesta este un DMV util, dar poate că nu este foarte clar cum să lucrăm cu el.
Scenariul din Fig. 2 ajută la investigarea situațiilor neobișnuite la completarea jurnalului de tranzacții. Se întoarce modelul de recuperare, o descriere a factorilor care cauzează trunchierea log întârziere (log reutilizare așteptați), dimensiunea jurnalului de tranzacții, utilizați spațiul jurnal, procentajul de spațiu utilizat, nivelul de compatibilitate și setările de scanare pagini pentru fiecare bază de date, de date SQL Server de instanța curentă.
Fig. 2. Determinați modul de completare a jurnalului de tranzacții utilizând acest script
Interogarea din Fig. 2 este util pentru evaluarea unui server de baze de date necunoscute. În plus, este și mai util în termeni de observație. De exemplu, dacă descrierea factorului care împiedică trunchierea jurnalului are o valoare neobișnuită precum ACTIVE_TRANSACTION, iar jurnalul de tranzacții este de 85% plin, timpul pentru a suna alarma.
O astfel de observație este extrem de utilă în identificarea surselor și cauzelor așteptărilor și a altor probleme de performanță. Aceste studii vă vor ajuta să vă îndreptați eforturile pentru a optimiza performanța în direcția corectă.
Glenn Berry (Glenn Berry) - rulează un arhitect de baze de date la NewsGator Technologies în Denver, Colorado. El are titlul de MVP în SQL Server, și are un set de certificări Microsoft, inclusiv MCITP, MCDBA, MCSE, MCSD, MCAD și MCTS, ceea ce înseamnă că el într-adevăr îi place să ia examenele de certificare.
Louis Davidson (Louis Davidson) - lucrează în domeniul IT de peste 16 ani ca dezvoltator și arhitect al bazelor de date corporative. El a deținut titlul de SQL Server MVP timp de șase ani și a scris patru cărți despre proiectarea bazei de date. În prezent, este implicat în dezvoltarea arhitecturii de baze de date și a administrării DB în cadrul rețelei Christian Broadcasting Network, sprijinind activitatea filialelor din Virginia Beach, Virginia și Nashville, Tennessee.
Aflați mai multe despre SQL Server DMV Starter Pack pe red-gate.com.
Trimiteți-le prietenilor: