Om dina databasanvändare har klagat över att SQL Server-prestanda har varit svag på sistone, är det möjligt att du upplever effekterna av en eller flera SQL Server-flaskhalsar. Dessa flaskhalsar uppstår av en mängd olika anledningar, men de uppstår ofta som ett resultat av problem med minne, I/O eller CPU.
Även om det inte alltid är lätt att avgöra om prestandaproblem härrör från en SQL Server-flaskhals eller från en annan källa, kan du leta efter dessa vanliga symptom på flaskhalsar för att begränsa din sökning efter källan till problemet.
Vanliga symtom på SQL Server-flaskhalsar
- SQL-servern tar upp processorn
- Längre körtider på frågor
- Överdriven I/O
- Programlogg som visar meddelanden om slut på minnet
- Extrem aktivitet på diskarna
- Långa väntetider per I/O
Det plötsliga uppkomsten av ett eller flera av dessa symtom är en bra indikation på att du har en SQL Server-flaskhals någonstans i ditt system. Nu är det ditt jobb att hitta den.
Typer av SQL Server-flaskhalsar
Det finns tre huvudtyper av SQL Server-flaskhalsar:minne, I/O och CPU. Det är viktigt för DBA:er att vara bekanta med orsakerna, symtomen och korrigeringarna för var och en så att de snabbt kan identifiera och ta bort flaskhalsarna och minimera effekten av dålig prestanda. Vi har också inkluderat några av de bästa prestandaräknare att övervaka som hjälper till att identifiera prestandaflaskhalsar omedelbart.
Minnesflaskhalsar
Minnesflaskhalsar är vanligtvis ett resultat av att otillräckliga minnesresurser eller SQL Server-aktiviteter äter upp tillgängligt minne. Symtomen att hålla utkik efter inkluderar längre körningstider för frågor, överdriven I/O, meddelanden om att minnet är slut i programloggen och frekventa systemkrascher.
De bästa sätten att undvika minnesrelaterade flaskhalsar är att använda en frågeoptimerare för att bli av med onödiga eller föråldrade frågor och att konfigurera sidans förväntade livslängd i samband med buffertcacheförhållandet för att begränsa resor till disken. Om det är för sent att undvika flaskhalsen kan du prova att granska och ställa in frågor, konfigurera om minnet eller lägga till fysiskt minne.
Räknare att övervaka:tillgängligt minne, totalt serverminne, målserverminne, sidor/sek, buffertcache-träffförhållande
I/O-flaskhalsar
När det inte finns tillräckligt med lagringsutrymme för att stödja vanliga databasoperationer som TempDB, uppstår sannolikt I/O-flaskhalsar. Långa svarstider, långsamma applikationer och frekventa time-outs för uppgifter är alla viktiga indikatorer på att du har en I/O-flaskhals.
Du kan undvika den här typen av flaskhals genom att ställa in övervakning med larm och tröskelvarningar för att identifiera vilka aktiviteter som använder för stora mängder lagring. Om en I/O-flaskhals uppstår, begränsa läsning och skrivning av databassidor till och från disken. Detta kräver att du letar efter och korrigerar frekventa indexsökningar, ineffektiva frågor och inaktuell statistik.
Räknare att övervaka:genomsnittlig diskkölängd, genomsnittlig disksek/läs, genomsnittlig disksek/skriv, % disktid, genomsnittlig diskläsning/sek, genomsnittlig diskskrivning/sek
CPU-flaskhalsar
Den främsta orsaken till CPU-flaskhalsar är otillräckliga hårdvaruresurser. Det är ganska enkelt att identifiera denna flaskhals genom att kontrollera dina loggar för att avgöra om SQL Server använder överdriven CPU.
I en idealisk värld kan du undvika CPU-flaskhalsar genom att ha en dedikerad SQL Server-enbart-server och köra all annan programvara på en annan maskin. Eftersom det inte är ett alternativ för de flesta DBA:er, måste du veta hur du tar bort flaskhalsen för din CPU.
Det första steget är att identifiera CPU-svinen. När du väl vet var problemet ligger kan du finjustera frågor, förbättra dina körplaner eller konfigurera om systemet.
Räknare att övervaka:% processortid, batchbegäranden/sekund, SQL-kompilationer/sekund, SQL-omkompilationer/sekund
En berättelse om flaskhalsar i SQL Server-prestanda
"Vi har några flaskhalsar i SQL Server-prestanda att hantera", sa min chef sent en fredag.
"Hur vet du?" frågade jag.
"Försäljningen klagar på att deras databas har saktat ner på sistone. Vi måste se vad som händer med det.”
"OK. Jag ska boka ett konferensrum så att vi kan sätta oss ner och jobba på det.”
"Bry dig inte", sa chefen. "Det är sent på en fredag eftermiddag. Det betyder att det bästa sättet att studera flaskhalsar är med ett par egna. Vi går över till Pike Pub på marknaden.”
Vi gick in i baren undangömd på Pike Place Market och hittade ett litet bord vid fönstret.
"Vilken är din favorittyp av flaskhals?" frågade chefen.
Jag sa att jag var partisk för en stygg Nellie i flaskhalsen på 22 uns.
"Bra val", sa chefen. "Du beställer det, så tar jag Citrus Summer Ale."
Medan vi väntade på att våra flaskhalsar skulle komma, började vi med SQL Server-prestandaflaskhalsarna.
"Vi måste kolla efter problem på flera ställen", sa chefen. "De kan vara problem med minne, lagring eller processorer, men de ser alla ungefär likadana ut för användarna, eller hur? Smutsig prestation.
"CPU-problem är inte så svåra att hitta. Om det är problemet kommer vi att se att SQL Server tjuvstartar processorn och får den att spika hela tiden.
"Om det är ett minnesproblem kommer vi att se saker som längre körtider på frågorna och mer I/O eftersom applikationen måste fortsätta att ta slut till disken. Vi kan också kontrollera applikationsloggen för meddelanden som är slut på minnet.
"Och om flaskhalsen finns i lagring kommer vi att se extrem aktivitet på diskarna och långa väntetider per I/O."
Våra flaskhalsar kom. Vi studerade dem noggrant när vi övervägde prestationsproblemet djupare.
De många potentiella källorna till flaskhalsar i SQL Server-prestanda
"Tänk om det är ett I/O-problem?" Jag frågade. ”Vi bör se om WRITELOG väntetiden är för hög jämfört med den totala väntetiden. Eller, på tal om I/O, kanske det finns ett problem i själva SQL. Om det finns ineffektiv kod, som en NESTED LOOP JOIN på en stor tabell, kan SQL:n be om att läsa rader på den inre tabellen tusentals gånger. Det skulle verkligen straffa prestation.”
"Kan vara", sa chefen. "Komplexa sammanfogningar och sorteringsoperationer kan vara svåra, speciellt när tempdb-databasen inte är korrekt konfigurerad. Tempdb-konflikter ser ut som vanliga databaslås, men det är faktiskt låst argument på grund av samtidiga processer som alla väntar på sin tur på allokeringssidorna."
"Vilka verktyg kan vi använda för att undersöka alla dessa saker?" frågade jag.
"SQL Server hade en profilerare för att undersöka lagrade procedurer, men den är utfasad. Något sådant är ett bra sätt att hitta och diagnostisera problemfrågor, även om det bara är det första steget. Sedan finns det dynamiska hanteringsvyer och funktioner som hjälper dig att övervaka tillståndet för din server och databas, köra ner problem och justera din SQL.”
"Men SQL Server har så många rörliga delar," sa jag. "Jag skulle hellre ha ett verktyg som tittar på hela bilden från utsidan och in."
"Det skulle jag också göra. Helst från molnet, så vi behöver inte mer hårdvara och mjukvara på plats för att göra det."
Lätta prestandaflaskhalsar i SQL Server
Gäddan började bli trångt. Och, lika villiga som jag och chefen var att sitta på en krog och prata butik, det var trots allt fredag kväll. Vi hade andra ställen att gå till, andra människor att se och andra saker att prata om.
"Vad ska vi göra när vi har hittat flaskhalsarna?" frågade jag.
"Vi samlar ihop de vanliga misstänkta," sa chefen. "För att undvika att använda för mycket minne måste vi berätta för databasutvecklarna vilken av deras kod och frågor som läcker minne. Om vi hittar operationer som sammanfogar fyra, fem eller sex tabeller måste vi ge utvecklarna några SQL Server-inställningstips och bästa praxis för att göra om databasen. Eller så kanske vi har för många index och vi kanske slösar bort cykler på att uppdatera dem; det är lika svårt för CPU och I/O som att ha för få index. Vi kan ha problem med SQL Server-indexfragmentering, eller så kan vi behöva rensa bort de föråldrade och duplicerade indexen."
"Det är vettigt", sa jag. "Kanske måste vi kasta mer hårdvara på det. Snabbare diskar kan hjälpa till med I/O-flaskhalsar. Fler och snabbare processorer gör skillnad i fråga om svarstider. Och att lägga till RAM innebär mer SQL Server-skalbarhet, eller hur?”
"Ja," sa chefen, "men först vill jag vara säker på att grundorsaken inte är ett utvecklings- eller DevOps-problem. När jag är övertygad om att det inte är det, kommer jag att spela kortet Köp mer hårdvara."
Vi satt ett ögonblick och såg puben fyllas med fredagskvällens fester.
"Boss," frågade jag, "tror du att alla dessa människor vet hur sorglös en tillvaro de alla leder, utan bördan av att hantera blockerade sessioner, maximal I/O-väntning, förväntad livslängd för sidan och buffertcache-träffförhållanden?"
"Det är ett kors att bära, eller hur?" svarade chefen. "De flesta har ingen aning om vad vi går igenom. Bra att vi hanterar SQL Server-prestandaflaskhalsar så tyst, med så mycket grace under press och i så god smak. På tal om god smak, hur mår du med din flaskhals?”
Jag kollade. "Min flaskhals är tom. Det är min flaska också.”
"Min också. Dags att gå. Vi har arbete att göra.”
Är ett Zero SQL Server-flaskhalssystem möjligt?
Vi vet att det finns steg vi kan vidta för att undvika dessa tre vanliga typer av SQL Server-flaskhalsar. Men är det möjligt att konfigurera en SQL Server-databas så bra att den inte har några flaskhalsar?
Det korta svaret är förmodligen inte. Även den mest flitiga DBA kommer att ha SQL Server-flaskhalsar som dyker upp då och då. Men du kan vidta åtgärder för att proaktivt undvika flaskhalsar och minimera deras inverkan på prestanda. Brent Ozar erbjuder till exempel några bra tips för att övervaka Perfmon-räknare för att ställa in din SQL-server, och du kan använda vyn sys.dm_os_performance_counters för att identifiera flaskhalsar och korrigera dem snabbt.
SQL Server-flaskhalsar är ett faktum i DBA-livet. Lyckligtvis, med tillräcklig tillsyn, noggrann övervakning och frekvent justering av sökfrågor, kan prestandaproblem åtgärdas innan användarna ens vet att det finns ett problem.