Beskriv ventestatistikk

Fullført

En omfattende tilnærming til overvåking av serverytelse innebærer å evaluere hva serveren venter på. Ventestatistikk er intrikat, og SQL Server er utstyrt med hundrevis av ventetyper som overvåker hver kjørende tråd og logger hva tråden venter på.

Hvis du effektivt vil oppdage og feilsøke ytelsesproblemer med SQL Server, er det viktig å forstå hvordan ventestatistikk fungerer og hvordan databasemotoren bruker dem under behandling av forespørsler. Med denne kunnskapen kan du finne flaskehalser og optimalisere ytelsen mer nøyaktig.

Ventestatistikk er delt inn i tre typer ventetider: ressursventetider, køventetider og eksterne ventetider.

• Ressursventetid oppstår når en arbeidertråd i SQL Server ber om tilgang til en ressurs som for øyeblikket brukes av en tråd. Eksempler på ventende ressurser er låser, låselåser og disk-I/U-ventinger.
• Køventer oppstår når en arbeidertråd er inaktiv og venter på at arbeid skal tilordnes. Eksempel køventetider er vranglåsovervåking og slettet postopprydding.
• Eksterne ventetider oppstår når SQL Server venter på at en ekstern prosess, for eksempel en koblet serverspørring, skal fullføres. Et eksempel på en ekstern venting er et nettverksventeprogram relatert til å returnere et stort resultat satt til et klientprogram.

Du kan kontrollere sys.dm_os_wait_stats systemvisningen for å utforske alle ventetidene som oppstår av tråder som ble utført, og sys.dm_db_wait_stats for Azure SQL Database. Systemvisningen sys.dm_exec_session_wait_stats viser aktive venteøkter.

Med disse systemvisningene kan du få en oversikt over ytelsen til serveren og enkelt identifisere konfigurasjons- eller maskinvareproblemer. Disse dataene beholdes fra tidspunktet for oppstart av forekomsten, men dataene kan fjernes etter behov for å identifisere endringer.

Ventestatistikk evalueres som en prosentdel av den totale ventetiden på serveren.

Resultatet av denne spørringen fra sys.dm_os_wait_stats viser ventetidstypen og aggregasjonen av prosent av tiden som venter (ventprosentkolonne ) og gjennomsnittlig ventetid i sekunder for hver ventetype.

I dette tilfellet har serveren alltid på tilgjengelighetsgrupper på plass, som angitt av REDO_THREAD_PENDING_WORK og PARALLEL_REDO_TRAN_TURN ventetyper. Den relativt høye prosentandelen av CXPACKET og SOS_SCHEDULER_YIELD venter indikerer at denne serveren er under noe CPU-trykk.

Ettersom DMV-er gir en liste over ventetider med den høyeste tiden som er akkumulert siden forrige oppstart av SQL Server, kan innsamling og lagring av ventestatistikk med jevne mellomrom hjelpe deg med å forstå og korrelere ytelsesproblemer med andre databasehendelser.

Med tanke på at DMV-er gir deg en liste over ventetider med den høyeste tiden som er akkumulert siden forrige oppstart av SQL Server, kan innsamling og lagring av ventestatistikk med jevne mellomrom hjelpe deg med å forstå og korrelere ytelsesproblemer med andre databasehendelser.

Det finnes flere typer ventetider i SQL Server, men noen av dem er vanlige.

• RESOURCE_SEMAPHORE – indikerer at spørringer venter på at minnet skal bli tilgjengelig, ofte på grunn av store minnetilskudd til bestemte spørringer. Dette problemet manifesterer seg vanligvis som lange kjøretider for spørringer eller til og med tidsavbrudd. Årsaker til disse ventetypene kan inkludere utdatert statistikk, manglende indekser og høy samtidighet for spørring.

• LCK_M_X – angir ofte et blokkeringsproblem. Dette problemet kan løses ved å endre til READ COMMITTED SNAPSHOT isoleringsnivå, optimalisere indeksering for å redusere transaksjonstider eller forbedre transaksjonsbehandling i T-SQL-kode.

• PAGEIOLATCH_SH – denne ventetypen kan indikere problemer med indekser eller fraværet av nyttige indekser, noe som fører til at SQL Server skanner store mengder data. Hvis ventetiden er lav, men ventetiden er høy, kan det også tyde på problemer med lagringsytelsen. Du kan se denne virkemåten ved å analysere dataene i waiting_tasks_count og wait_time_ms kolonnene i sys.dm_os_wait_stats systemvisningen for å beregne gjennomsnittlig ventetid for en gitt ventetype.

• SOS_SCHEDULER_YIELD – denne ventetypen kan indikere høy CPU-utnyttelse, som er korrelert med enten høyt antall store skanninger eller manglende indekser, og ofte med høyt antall CXPACKET-ventinger .

• CXPACKET – En høy forekomst av denne ventetypen kan indikere feil konfigurasjon. Før SQL Server 2019 var standardinnstillingen for maksimal grad av parallellisme (MAXDOP) å bruke alle tilgjengelige CPUer for spørringer. I tillegg ble kostnadsterskelen for parallellisme satt til 5, noe som kan føre til at små spørringer utføres parallelt, noe som begrenser gjennomstrømming. Hvis du vil redusere denne ventetypen, kan du senke MAXDOP-innstillingen og øke kostnadsterskelen for parallellitet. CXPACKET-ventetypen kan imidlertid også indikere høy CPU-utnyttelse, som vanligvis løses gjennom indeksjustering.

• PAGEIOLATCH_UP – Denne ventetypen på datasidene 02:1:1 kan indikere TempDB-strid på PFS-datasider (Page Free Space). Hver datafil har én PFS-side per 64 MB data. Denne ventetiden skyldes vanligvis bare at én TempDB-fil, som før SQL Server 2016, var standard virkemåte å bruke én datafil for TempDB. Den beste fremgangsmåten for TempDB er å bruke én fil per CPU-kjerne, opptil åtte filer. Det er også viktig å sikre at TempDB-datafilene har samme størrelse og har de samme innstillingene for automatisk utvekst for å sikre at de brukes jevnt. SQL Server 2016 og høyere kontrollerer veksten av TempDB-datafiler for å sikre at de vokser på en konsekvent og samtidig måte.

I tillegg til DMV-ene som er nevnt tidligere, sporer spørringslageret også ventetider som er knyttet til bestemte spørringer. Selv om ventedataene som spores av spørringslageret, ikke er like detaljerte som dataene i DMV-ene, gir den fortsatt en nyttig oversikt over hva en spørring venter på.