Hvis dine databasebrugere har brokket sig over, at SQL Server-ydeevnen har været svag på det seneste, er det muligt, at du oplever virkningerne af en eller flere SQL Server-flaskehalse. Disse flaskehalse opstår af forskellige årsager, men de opstår ofte som følge af problemer med hukommelse, I/O eller CPU.
Selvom det ikke altid er let at afgøre, om ydeevneproblemer stammer fra en SQL Server-flaskehals eller fra en anden kilde, kan du kigge efter disse almindelige symptomer på flaskehalse for at hjælpe med at indsnævre din søgning efter kilden til problemet.
Almindelige symptomer på SQL Server-flaskehalse
- SQL-serveren hæver processoren
- Længere eksekveringstider på forespørgsler
- Overdreven I/O
- Programlog, der viser meddelelser, der mangler hukommelse
- Ekstrem aktivitet på diskene
- Lange ventetider pr. I/O
Den pludselige optræden af et eller flere af disse symptomer er en god indikation på, at du har en SQL Server-flaskehals et eller andet sted i dit system. Nu er det din opgave at finde den.
Typer af SQL Server-flaskehalse
Der er tre hovedtyper af SQL Server-flaskehalse:hukommelse, I/O og CPU. Det er vigtigt for DBA'er at være bekendt med årsagerne, symptomerne og rettelserne for hver enkelt, så de hurtigt kan identificere og fjerne flaskehalsene og minimere virkningen af dårlig ydeevne. Vi har også inkluderet nogle af de bedste ydeevnetællere til at overvåge, som vil hjælpe med at identificere ydeevneflaskehalse med det samme.
Hukommelsesflaskehalse
Hukommelsesflaskehalse er normalt et resultat af utilstrækkelige hukommelsesressourcer eller SQL Server-aktiviteter, der spiser tilgængelig hukommelse. Symptomerne, du skal være opmærksom på, omfatter længere forespørgselsudførelsestider, overdreven I/O, meddelelser, der mangler hukommelse i applikationsloggen, og hyppige systemnedbrud.
De bedste måder at undgå hukommelsesrelaterede flaskehalse på er at bruge en forespørgselsoptimering for at slippe af med unødvendige eller forældede forespørgsler og at konfigurere sidelevetid i forbindelse med buffercache hit ratio for at begrænse trips til disken. Hvis det er for sent at undgå flaskehalsen, kan du prøve at gennemgå og justere forespørgsler, omkonfigurere hukommelsen eller tilføje fysisk hukommelse.
Tællere til overvågning:tilgængelig hukommelse, samlet serverhukommelse, målserverhukommelse, sider/sek., buffercache hit ratio
I/O-flaskehalse
Når der ikke er nok lagerplads til rådighed til at understøtte almindelige databaseoperationer såsom TempDB, vil der sandsynligvis opstå I/O-flaskehalse. Lange svartider, langsommere programmer og hyppige timeouts for opgaverne er alle nøgleindikatorer på, at du har en I/O-flaskehals.
Du kan undgå denne type flaskehals ved at opsætte overvågning med alarmer og tærskelalarmer for at identificere, hvilke aktiviteter der bruger for store mængder lager. Hvis der opstår en I/O-flaskehals, skal du begrænse læsning og skrivning af databasesider til og fra disken. Dette kræver, at du tjekker for og retter hyppige indeksscanninger, ineffektive forespørgsler og forældede statistikker.
Tællere, der skal overvåges:gennemsnitlig diskkølængde, gennemsnitlig disksek./læs, gennemsnitlig disksek./skrive, % disktid, gennemsnitlig disklæsning/sek., gennemsnitlig diskskrivning/sek.
CPU-flaskehalse
Den primære årsag til CPU-flaskehalse er utilstrækkelige hardwareressourcer. Det er ret nemt at identificere denne flaskehals ved at tjekke dine logfiler for at afgøre, om SQL Server bruger for meget CPU.
I en ideel verden kunne du undgå CPU-flaskehalse ved at have en dedikeret SQL Server-only server og køre al den anden software på en anden maskine. Fordi det ikke er en mulighed for de fleste DBA'er, bliver du nødt til at vide, hvordan du fjerner flaskehalsen for din CPU.
Det første trin er at identificere CPU-svinene. Når du ved, hvor problemet ligger, kan du justere forespørgsler, forbedre dine eksekveringsplaner eller omkonfigurere systemet.
Tællere, der skal overvåges:% processortid, batchanmodninger/sek., SQL-kompilationer/sek., SQL-rekompileringer/sek.
En historie om flaskehalse i SQL Server-ydelse
"Vi har nogle flaskehalse i SQL Server-ydelsen at håndtere," sagde min chef sent en fredag.
"Hvordan ved du det?" spurgte jeg.
"Salget klager over, at deres database er blevet langsommere på det seneste. Vi er nødt til at se, hvad der sker med det.”
"OKAY. Jeg booker et mødelokale, så vi kan sætte os ned og arbejde på det.”
"Gør det ikke," sagde chefen. "Det er sent på en fredag eftermiddag. Det betyder, at den bedste måde at studere flaskehalse på er med et par af vores egne. Vi går over til Pike Pub på markedet.”
Vi gik ind i baren gemt væk i Pike Place Market og fandt et lille bord ved vinduet.
"Hvad er din foretrukne flaskehals?" spurgte chefen.
Jeg sagde, at jeg var delvis over for en fræk Nellie i flaskehalsen på 22 ounce.
"Godt valg," sagde chefen. "Du bestiller det, og jeg vil have Citrus Summer Ale."
Mens vi ventede på, at vores flaskehalse ankom, gik vi i gang med SQL Server-ydelsesflaskehalsene.
"Vi bliver nødt til at tjekke for problemer flere steder," sagde chefen. "De kan være problemer med hukommelse, lager eller processorer, men de ser alle nogenlunde ens ud for brugerne, ikke? Smuk præstation.
"CPU-problemer er ikke så svære at finde. Hvis det er problemet, så vil vi se, at SQL Server hæver processoren og får den til at spike hele tiden.
"Hvis det er et hukommelsesproblem, vil vi se ting som længere udførelsestider på forespørgslerne og mere I/O, fordi applikationen skal blive ved med at løbe ud til disken. Vi kan også tjekke applikationsloggen for meddelelser, der ikke er mere hukommelse.
"Og hvis flaskehalsen er på lager, vil vi se ekstrem aktivitet på diskene og lange ventetider pr. I/O."
Vores flaskehalse ankom. Vi studerede dem omhyggeligt, da vi overvejede ydeevneproblemet dybere.
De mange potentielle kilder til flaskehalse i SQL Server-ydelse
"Hvad hvis det er et I/O-problem?" Jeg spurgte. ”Vi bør se, om WRITELOG ventetiden er for høj i forhold til den samlede ventetid. Eller, når vi taler om I/O, måske er der et problem i selve SQL'en. Hvis der er ineffektiv kode, som en NESTED LOOP JOIN på en enorm tabel, kan SQL'en bede om at læse rækker på den indre tabel millioner af gange. Det ville virkelig straffe præstation.”
"Det kunne være," sagde chefen. "Komplekse sammenføjninger og sorteringsoperationer kan være svære, især når tempdb-databasen ikke er konfigureret korrekt. Tempdb-konflikter ligner almindelige databaselåse, men det er faktisk låst strid på grund af samtidige processer, der alle venter på deres tur på allokeringssiderne."
"Hvilke værktøjer kan vi bruge til at undersøge alle disse ting?" spurgte jeg.
"SQL Server havde en profiler til at undersøge lagrede procedurer, men den er forældet. Sådan noget er en god måde at finde og diagnosticere problemforespørgsler på, selvom det kun er det første skridt. Så er der dynamiske administrationsvisninger og funktioner, der hjælper dig med at overvåge din servers og databases tilstand, køre problemer ned og justere din SQL."
"Men SQL Server har så mange bevægelige dele," sagde jeg. "Jeg vil hellere have et værktøj, der ser på hele billedet udefra og ind."
"Det ville jeg også. Helst fra skyen, så vi behøver ikke mere hardware og software på stedet for at gøre det."
Afhjælpning af ydeevneflaskehalse i SQL Server
Gedde var begyndt at blive overfyldt. Og lige så villige som chefen og jeg var til at sidde på et værtshus og snakke butik, så var det trods alt fredag aften. Vi havde andre steder at tage hen, andre mennesker at se og andre ting at tale om.
"Hvad skal vi gøre, når vi har fundet flaskehalsene?" spurgte jeg.
"Vi samler de sædvanlige mistænkte," sagde chefen. "For at undgå at bruge for meget hukommelse, er vi nødt til at fortælle databaseudviklerne, hvilken af deres kode og forespørgsler, der lækker hukommelse. Hvis vi finder operationer, der forbinder fire, fem eller seks tabeller, bliver vi nødt til at give udviklerne nogle SQL Server tuning tips og bedste praksis for at redesigne databasen. Eller vi kan have for mange indekser, og vi spilder måske cyklusser på at opdatere dem; det er lige så hårdt for CPU'en og I/O'en som at have for få indekser. Vi kan have et problem med SQL Server-indeksfragmentering, eller vi bliver måske nødt til at luge ud i de forældede og duplikerede indekser."
"Det giver mening," sagde jeg. "Måske skal vi kaste mere hardware efter det. Hurtigere diske kan hjælpe med I/O-flaskehalse. Flere og hurtigere CPU'er gør en forskel i forespørgselssvartider. Og tilføjelse af RAM betyder mere SQL Server-skalerbarhed, ikke?”
"Ja," sagde chefen, "men først vil jeg være sikker på, at grundårsagen ikke er et udviklings- eller DevOps-problem. Når jeg er overbevist om, at det ikke er det, så vil jeg spille kortet Køb mere hardware."
Vi sad et øjeblik og så pubben fyldes op med fredag aften festglade.
"Boss," spurgte jeg, "tror du, at alle disse mennesker ved, hvor ubekymret en tilværelse de alle fører, uden byrden ved at håndtere blokerede sessioner, maksimal I/O-ventetid, forventet sidelevetid og buffercache-hitforhold?"
"Det er et kors at bære, er det ikke?" svarede chefen. »De fleste aner ikke, hvad vi går igennem. Godt vi håndterer SQL Server-ydelsesflaskehalse så stille og roligt, med så meget ynde under pres og i så god smag. Apropos god smag, hvordan har du det på din flaskehals?”
Jeg kontrollerede. "Min flaskehals er tom. Det er min flaske også.”
"Også min. Tid til at gå. Vi har arbejde at gøre."
Er et Zero SQL Server Bottleneck System muligt?
Vi ved, at der er trin, vi kan tage for at undgå disse tre almindelige typer af SQL Server-flaskehalse. Men er det muligt at konfigurere en SQL Server-database så godt, at den ikke har nogen flaskehalse?
Det korte svar er nok ikke. Selv den mest flittige DBA vil have SQL Server flaskehalse dukker op i ny og næ. Men du kan tage skridt til proaktivt at undgå flaskehalse og minimere deres indvirkning på ydeevnen. For eksempel tilbyder Brent Ozar nogle gode tips til at overvåge Perfmon-tællere for at tune din SQL Server, og du kan bruge sys.dm_os_performance_counters-visningen til at hjælpe med at identificere flaskehalse og rette dem hurtigt.
SQL Server-flaskehalse er et faktum i DBA-livet. Heldigvis kan ydeevneproblemer løses, før brugerne overhovedet ved, at der er et problem, med tilstrækkelig overvågning, omhyggelig overvågning og hyppig justering af forespørgsler.