(Postat inițial pe DBA.StackExchange.com, dar închis, sperăm că mai relevant aici.)
Alexandru și cel Groaznic, îngrozitor, nimic bun, foarte rău... copii de rezervă.
Pregatirea:
Am un on-premise SQL Server 2016 Standard Edition instanță care rulează pe a mașină virtuală de la VMWare.
@@Versiune:
Microsoft SQL Server 2016 (SP2-CU17) (KB5001092) - 13.0.5888.11 (X64)
19 martie 2021 19:41:38 Copyright (c) Microsoft Corporation Standard
Ediție (64 de biți) pe Windows Server 2016 Datacenter 10.0 (Build
14393: ) (Hypervisor)
Serverul în sine este alocat în prezent 8 procesoare virtuale, are 32 GB memorie, și toate discurile sunt NVM-uri care ocolesc 1 GB/sec de I/O. Bazele de date în sine trăiesc pe unitatea G:, iar copiile de rezervă sunt stocate separat pe unitatea P:. Dimensiunea totală a tuturor bazelor de date este de aproximativ 500 GB (înainte de a fi comprimate în fișierele de rezervă).
Planul de întreținere rulează o dată pe noapte (în jurul orei 22:30) pentru a face o copie de rezervă completă pe fiecare bază de date de pe server. Nimic altceva ieșit din comun nu rulează pe server și nici altceva nu rulează la acel moment în special. Planul de alimentare de pe server este setat la „Echilibrat” (și „Opriți hard diskul după” este setat la 0 minute, adică nu îl opriți niciodată).
Ce s-a întâmplat:
În ultimul an sau cam asa ceva, durata totală de execuție a lucrării planului de întreținere a durat aproximativ 15 minute total de completat. De săptămâna trecută, a crescut vertiginos, ajungând la aproximativ 40 de ori mai mult, aproximativ 15 ore a termina.
Singurul lucru de care știu că am schimbat în aceeași zi în care planul de întreținere a încetinit a fost că următoarele actualizări Windows au fost instalate pe mașină înainte de rularea planului de întreținere:
- KB890830
- KB5004752
- KB5005043
- VMWare - SCSIAdapter - 1.3.17.0
- VMWare - Display - 8.17.2.14
Avem, de asemenea, o altă instanță SQL Server furnizată în mod similar pe o altă VM care a suferit aceleași actualizări Windows și, ulterior, a experimentat backup-uri mai lente. Crezând că actualizările Windows au fost cauza directă, le-am anulat complet, iar planul de întreținere a copiilor de rezervă este încă extrem de lent oricum. În mod ciudat, restaurarea copiilor de rezervă pentru o anumită bază de date are loc foarte rapid și utilizează aproape 1 GB/sec de I/O pe NVM-urile.
Lucruri pe care le-am încercat:
Când folosesc sp_whoisactive de la Adam Mechanic, am identificat că Tipurile de Ultima așteptare ale proceselor de backup indică întotdeauna o problemă de performanță a discului.Întotdeauna văd BACKUPBUFFER și BACKUPIO tipuri de așteptare, pe lângă ASYNC_IO_COMPLETION:
Când vă uitați la Monitorul resurselor de pe server însuși, în timpul copierilor de rezervă, secțiunea I/O pe disc arată că I/O totală utilizată este de numai aproximativ 14 MB/sec (cel mai mult pe care l-am văzut vreodată de când a apărut această problemă este 30 MB/sec):
După ce am dat peste acest util Brent Ozar articol despre utilizarea DiskSpd, am încercat să îl rulez eu însumi sub parametri similari (doar scăzând numărul de fire la 8 deoarece am 8 procesoare virtuale pe server și setând scrierile la 50%). Aceasta este comanda exactă diskspd.exe -b2M -d60 -o32 -h -L -t8 -W -w50 „C:\Utilizatori\...\Desktop\Microsoft DiskSpd\Test\LargeFile.txt”. Am folosit un fișier text pe care l-am generat manual, care are puțin sub 1 GB. Cred că I/O pe care l-a măsurat pare OK, dar latența discului arătau niște numere ridicole:
Rezultatele DiskSpd par literalmente incredibile. După ce am citit în continuare, am dat peste o interogare de la Paul Randall care returnează valorile de latență a discului pe bază de date. Acestea au fost rezultatele:
Cea mai slabă latență de scriere a fost de 63 de milisecunde, iar cea mai proastă latență de citire a fost de 6 milisecunde, așa că pare a fi o mare variație față de DiskSpd și nu pare suficient de groaznică pentru a fi cauza principală a problemei mele. Verificând lucrurile în continuare, am rulat câteva contoare PerfMon pe serverul însuși, per acest articol Microsoft, iar acestea au fost rezultatele:
Nimic extraordinar aici, valoarea maximă a tuturor contoarelor pe care le-am măsurat a fost 0,007 (care cred că sunt milisecunde?). În cele din urmă, am pus echipa mea de infrastructură să verifice valorile de latență a discului pe care le înregistra VMWare în timpul lucrării de backup și acestea au fost rezultatele:
Se pare că, în cel mai rău caz, a existat un vârf de latență de aproximativ 200 de milisecunde în jurul miezului nopții, iar cea mai mare I/O a fost de 600 KB/sec (ceea ce nu prea înțeleg, deoarece Monitorul resurselor arată că backup-urile folosesc cel puțin aproximativ 14 MB/sec de I/O).
Alte lucruri pe care le-am încercat:
Tocmai am încercat să refac una dintre bazele de date mai mari (este de aproximativ 250 GB) și a durat doar aproximativ 8 minute în total pentru restaurare. Apoi am încercat să alerg DBCC CHECKDB pe el și a durat un total de 16 minute pentru a rula (nu sunt sigur dacă acest lucru este normal), dar Resource Monitor a arătat probleme similare de I/O (cel mai mare I/O pe care l-a folosit vreodată a fost de 100 MB/s), fără a rula nimic altceva:
Iată rezultatele sp_whoisactive când am alergat prima dată DBCC CHECKDB și apoi, după ce a fost finalizat cu 5%, observați că timpul estimat rămas a crescut cu aproximativ 5 minute, chiar și după ce a fost deja terminat cu 5%.
Start:
5% gata:
Bănuiesc că acest lucru este normal, deoarece este doar o estimare, iar 16 minute nu pare prea rău pentru o bază de date de 250 GB (deși nu sunt sigur dacă este normal), dar din nou I/O-ul a ajuns la maxim. aproximativ 10% din capabilitățile unității, fără a rula nimic altceva pe server sau pe instanța SQL.
Acestea sunt rezultatele de DBCC CHECKDB, nu au fost raportate erori.
De asemenea, m-am confruntat cu probleme ciudate de încetinire cu MICĂ comanda. Tocmai am încercat MICĂ baza de date care avea 5% spațiu de eliberat (aproximativ 14 GB). A durat doar aproximativ 1 minut pentru a finaliza 90% din MICĂ:
Aproximativ 5 minute mai târziu, și este încă blocat la același procent de finalizare, iar copiile de rezervă ale jurnalului de tranzacții (care se termină de obicei în 1-2 secunde) au fost în dispută timp de aproximativ 30 de secunde:
15 minute mai târziu și MICĂ tocmai se termină, în timp ce copiile de rezervă ale jurnalului de tranzacții sunt încă în disputa de aproximativ 6 minute și sunt finalizate doar în proporție de 50%. Cred că au terminat imediat după aceea, deoarece MICĂ terminat. Tot timpul în care Monitorul resurselor a arătat că I/O suge încă:
Apoi am primit o eroare cu MICĂ comanda când s-a terminat:
am reîncercat MICĂ din nou și a rezultat în același rezultat exact ca mai sus.
Apoi am încercat să scriptez manual o copie de rezervă T-SQL într-un fișier de pe unitatea P: și care a funcționat lent, la fel ca și sarcina de rezervă a planului de întreținere:
Am ajuns să-l anulez după aproximativ 3 minute și s-a derulat imediat înapoi.
Rezumat:
Întâmplător, sarcina planului de întreținere a backupurilor a devenit de aproximativ 40 de ori mai lentă (de la 15 minute la 15 ore) în fiecare noapte, imediat după instalarea actualizărilor Windows. Revenirea acelor actualizări Windows nu a rezolvat problema. SQL Server Wait Types, Resource Monitor și Microsoft DiskSpd indică o problemă de disc (I/O în special), dar toate celelalte măsurători din interogarea lui Paul Randall, PerfMon și VMWare Logs nu raportează nicio problemă cu discurile. Restaurarea copiilor de rezervă pentru o anumită bază de date este rapidă și utilizează aproape 1 GB/sec I/O. ma scarpin in cap...
