Brent Ozar, Microsoft Certified Master diskuterede for nylig parallelitet i SQL Server, specifikt ventetyperne CXPACKET og CXCONSUMER i sin sidste del af Quest's Database Training Days Fall Series. På sin sædvanlige humoristiske og tilgængelige måde afmystificerede Brent begreberne parallelisme og forklarede, hvordan man håndterer det, når du ser for mange CXPACKET og CXCONSUMER ventestatistikker.
For det første, hvad er parallelisme, og hvorfor får SQL Server forespørgsler til at køre parallelt?
Enkelt sagt genkender SQL Server automatisk, at en bestemt forespørgsel har en stor arbejdsbyrde, og den bestemmer, at arbejdet kan udføres mere effektivt på tværs af flere processorer end med kun én. Dette er generelt en smart beslutning, men det kan løbe ind i problemer, når SQL Server ikke balancerer belastningen på tværs af de tråde, der udfører opgaven.
Forstå ventetyperne CXPACKET og CXCONSUMER
CXPACKET og CXCONSUMER er ventetyper, der indikerer, at arbejdet ikke er lige afbalanceret. Når du ser disse ventestatistikker på din server, vil du vide, at SQL Server kører forespørgsler parallelt, men ikke gør et godt stykke arbejde med at distribuere dem på tværs af tilgængelige processorer.
Enhver databaseprofessionel er bekendt med begrebet "omkostning" for at udtrykke, hvor dyr en forespørgsel er at udføre med hensyn til ressourceforbrug. Disse "query bucks" er et omtrentligt mål for arbejde og et vigtigt signal om, hvorvidt forespørgslen vil køre parallelt eller ej. En billig forespørgsel behøver ikke at køre parallelt, men en dyr en vil. Målet er at udføre forespørgslen så hurtigt og effektivt som muligt, så den næste i rækken kan begynde. SQL Server udpeger en tråd som en skemalægger, og denne tråd, som Brent anså for "robottens overherre", vil tildele dele af den parallelle arbejdsbyrde til arbejdertrådene eller "robottens håndlangere".
Parallelisme og robottens overherre
Brent dykkede ind i en demo for at vise, hvordan dette fungerer. Ved at bruge Stack Overflow-databasen oprettede han et billigt databaseopslag, der var meget hurtigt på grund af tilstedeværelsen af et indeks. Udførelsesplanen var ret ligetil og krævede ikke parallelitet for at køre.
Men da han introducerede et opslag for noget, der ikke var i indekset, ændrede tingene sig ved at fremtvinge et nøgleopslag for hver række i tabellens grupperede indeks. SQL Server erkendte, at dette ville være en masse arbejde, så den introducerede parallelitet og indikerede som sådan med et ikon på udførelsesplanen. Hvis udførelsesplanen var tredimensionel, ville du være i stand til at se de flere tråde stablet op, men da det ikke er det, skal du se statistikken for at se oplysninger såsom de logiske læsninger udført af hver CPU-tråd.
SQL Server tildelte dog kun denne opgave til nogle få tråde, ikke dem alle. Brent forklarede, at alt, der sker ud over det parallelle ikon, kun sker på de tildelte processorer. Så de tråde, der udførte de indledende læsninger, er nu de eneste, der også laver nøgleopslag. Robot-overlord bad kun nogle få håndlangere om at udføre hele opgaven i stedet for at bede alle håndlangere om at slå til.
Han fortsatte med at forklare, at SQL Server skal redegøre for, hvad trådene laver, samt spore, hvad robotoverherren gør. I de tidlige dage var alt dette arbejde repræsenteret af én ventestatistik, men dette gav ikke mening, for uanset hvad skal overherren stadig vente, mens alle tråde fungerer. Så en ny ventetype blev introduceret – dette var CXCONSUMER og den sporer, hvad planlægger/overlord-tråden laver, mens CXPACKET sporer, hvad arbejder-/minion-trådene laver.
Brent gik tilbage til forespørgslen for at gøre den endnu mere kompleks ved at tilføje en sortering. Nu bliver det endnu mere klart, at parallelisme forårsager et problem frem for at gøre driften mere effektiv. Arbejdet er blevet endnu mere ubalanceret på tværs af de få arbejdstråde, og nogle løber tør for hukommelse og spilder til disk. Han tilføjede en joinforbindelse, hvilket belastede de arbejdende kerner yderligere, som ikke får nogen hjælp fra de ikke-arbejdende. CXPACKET-statistikken fortsatte med at stige.
Hvad kan du gøre i denne situation? Beslutningen om parallelitet sker på serverniveau og ikke på forespørgselsniveau, så det vil kræve nogle konfigurationsændringer.
Vurderer nøglekonfigurationer
Vi har allerede lært, at hvis forespørgselsomkostningerne er højere end et vist niveau, får det SQL Server til at parallelisere. Små forespørgsler bliver begrænset til en enkelt tråd. Men hvad styrer tærsklen? Det er en egenskab kaldet Cost Threshold for Parallelism (CTFP). Som standard, hvis udførelsesplanen bestemmer, at omkostningerne er højere end 5 forespørgselsbukke, vil forespørgslen blive paralleliseret. Selvom der ikke er nogen vejledning i, hvordan man indstiller dette, anbefaler Brent et tal, der er større end 50. Dette vil slippe af med parallelisme for trivielle forespørgsler.
En anden konfiguration er den maksimale grad af parallelisme (MAXDOP), som beskriver antallet af tråde, som SQL Server vil tildele forespørgslen. Standardværdien her er nul, hvilket betyder, at SQL Server kan bruge alle tilgængelige processorer, op til 64, til at udføre forespørgslen. Indstilling af MAXDOP-indstillingen til 1 begrænser SQL Server til kun at bruge én processor – faktisk tvinger en seriel plan til at udføre forespørgslen. SQL Server vil anbefale en MAXDOP-værdi baseret på antallet af serverkerner, du har, men generelt giver en lavere MAXDOP mening, da der ikke vil være mange gange, at alle kerner er nødvendige.
Brent foretog justeringer af disse to konfigurationer og kørte sin forespørgsel igen. Denne gang kunne vi se, at flere kerner var involveret i den parallelle operation. CXPACKET ventestatistikken var lavere, hvilket betød, at belastningen var mere jævnt afbalanceret på tværs af flere kerner end før.
Tips til bekæmpelse af CXPACKET og CXCONSUMER ventestatistikker
Brent anbefaler følgende trin, hvis du ser overdreven CXPACKET og CXCONSUMER ventestatistikker:
- Indstil CTFP og MAXDOP pr. branche bedste praksis, og lad derefter disse indstillinger bage i et par dage. Dette rydder planens cache og tvinger SQL Server til at genopbygge forespørgselsudførelsesplaner (genvurdere omkostningerne).
- Foretag indeksforbedringer, der reducerer det tidspunkt, hvor forespørgsler går parallelt for at udføre scanninger og sorteringer. Lad nye indekser bage, og søg derefter efter forespørgsler, der stadig gør en masse arbejde.
- Juster disse forespørgsler og lad dem bage i et par dage.
- Til sidst, hvis parallelisme stadig er et alvorligt problem, skal du begynde at lede efter de specifikke forespørgsler med parallelitetsproblemer.
For endnu mere indsigt kan du se hele Brents træningssession på CXPACKET og CXCONSUMER ventestatistikker on-demand nedenfor.