I det här inlägget kommer jag att diskutera en allmän metod för att felsöka CPU-prestandaproblem. Jag gillar att tillämpa metoder som standard och jag gillar också att bygga effektivitet i hur jag felsöker problem baserat på tidigare erfarenheter. Utan en generell ram blir det för lätt att missa den verkliga grundorsaken mitt i en kris.
Stegen jag kommer att beskriva i det här inlägget är följande:
- Definiera problemet
- Verifiera de nuvarande villkoren
- Svara "Är det SQL Server"?
- Identifiera CPU-konsumenter
- Mata mönstret och lös ut
Den här artikeln kommer att täcka vart och ett av dessa steg. Jag kommer att anta att du kanske inte använder ett övervakningsverktyg från tredje part. Om du är det, gäller ramverket här fortfarande, men dina datakällor och verktyg till ditt förfogande kommer att variera från vad jag beskriver.
Definiera problemet
Först måste vi ta reda på frågan. När någon kommer fram till dig och säger att de ser ett problem med CPU-prestanda kan detta betyda hur många olika saker som helst. Så den första uppgiften är att förstå vad problemet med CPU-prestanda är för närvarande.
Några vanliga kategorier inkluderar:
- Tillgängligheten påverkas på grund av "peggade processorer". Till exempel – alla schemaläggare som körs på 100 % över hela linjen och genomströmningen stannar eller minskar avsevärt.
- Försämring av prestanda på grund av "högre än normal" CPU-användning. Så vi är inte kopplade, men dina processorer körs med en högre procentandel än vad som är vanligt och förmodligen påverkar det prestandan.
- En annan vanlig kategori av problem med CPU-prestanda är "vinnare och förlorare"-scenariot där arbetsbelastningar tävlar mot varandra. Du kanske har en OLTP-arbetsbelastning som stöter på minskad genomströmning på grund av en parallellkörande rapportfråga.
- Ett annat problem kan vara att stöta på en tipppunkt – där den totala kapaciteten och skalbarhetsbegränsningarna för ditt system drabbas vid en viss punkt.
Jag nämner dessa övergripande kategorier som en utgångspunkt, men jag vet att det ofta kan finnas stora beroenden över dessa frågor och den ena kategoriseringen kan smälta in i den andra. Med det sagt är det första steget att definiera symptomen och problemen så tydligt som möjligt.
Validera de nuvarande villkoren
Oavsett om problemet inträffade tidigare eller pågår just nu är det viktigt att få så mycket bakgrundsinformation om systemet, arbetsbelastningen och konfigurationerna som möjligt. Om du använder baslinjer och run-books spårar du helst mycket av denna information redan. Om inte, fråga dig själv hur snabbt du kan få svar på dessa frågor klockan 02:00 mitt i en kris.
Följande underavsnitt täcker viktiga datapunkter som jag vanligtvis är intresserad av för ett problem med CPU-prestanda.
- Hur många uttag och kärnor?
- Är hypertrådning aktiverat?
- Vad är processormodellen, arkitekturen (32-bitar/64-bitars)?
- Är det här en virtuell gäst?
- I så fall kommer du nu också att vara intresserad av detaljer om värden och de andra virtuella gästerna som du delar resurser med.
- Finns det några CPU-relaterade inställningar i kraft?
- Till exempel Hyper-V CPU
- Hur många vCPU:er är tilldelade mellan gästerna?
- Hur många vCPU:er har den här gästen?
- Har gästen nyligen migrerat till en ny värd innan problemet uppstod?
- Max grad av parallellitetsinställning
- Kostnadströskel för parallellitetsalternativ
- Inställning för processoraffinitet
- Inställning för prioriterad ökning
- Max arbetstrådsinställning
- Lättviktspoolinställning
- Vad är inställningen för energialternativ? (OS-nivå, VM-värd eller BIOS-kontrollerad)
- Hög prestanda, balanserad, energisparande?
- Är det konfigurerat utöver standardinställningarna?
- Ser du några ovanliga varningar eller fel?
Fysisk serverinformation
Virtuella serverdetaljer
Reserv, VMware CPU-reservation, Hyper-V CPU relativ vikt och VMware CPU Shares.
SQL Server-instanskonfigurationsinställningar
De tre första konfigurationerna kan kräva ytterligare diskussion. Det finns sällan absoluta värden för dessa inställningar.
När det gäller de tre sista inställningarna, som "prioritetsförstärkning", om jag ser att de är på icke-standardvärden, kommer jag definitivt att trycka på för mer bakgrundsinformation och historik.
Inställningar för CPU-strömalternativ
Inställningar för energialternativ under "Hög prestanda" är fortfarande mycket vanliga och bör inte ignoreras för servrar som är värd för SQL Server-instanser.
Resource Governor-konfiguration
Jag tycker fortfarande att det är sällsynt att stöta på kunder som överhuvudtaget använder den här funktionen, men det är lätt att validera om den används och kommer att vara värt det för de gånger som den faktiskt är konfigurerad utöver standardinställningen.
SQL Server-fellogg och Windows-händelseloggar
Varför leta efter ett CPU-problem i fel- och händelseloggarna? Ibland kan uppströmsproblem orsaka nedströmsprestandaproblem i SQL Server. Du vill inte slösa tid på att justera en fråga eller lägga till ett nytt index när du uppströms rotorsak är ett problem med maskinvarukomponentförsämring.
Svara "Är det SQL Server?"
Det låter uppenbart när jag frågar det, men du vill verkligen inte spendera en betydande mängd tid på att felsöka ett problem med hög CPU i SQL Server om den skyldige inte faktiskt är SQL Server.
Ta istället en snabb stund för att kontrollera vilken process som förbrukar mest CPU. Det finns flera alternativ att välja mellan, inklusive:
- Process:% användartid (användarläge)
- Process:% privilegierad tid (kärnläge)
- Task Manager
- Process Explorer
- Senaste CPU-information via sys.dm_os_ring_buffers eller systemets hälsosession för de specifika SQL Server-instanser som körs på systemet
Om det är SQL Server och du har flera SQL Server-instanser att välja mellan, se till att du felsöker rätt SQL Server-instans på värden. Det finns några sätt att göra detta, inklusive användningen av SELECT SERVERPROPERTY('processid') för att hämta PID och sedan associera det till Task Manager eller Process Explorer.
När du har bekräftat att det är SQL Server, ser du hög användartid eller privilegierad (kärn)tid? Återigen kan detta bekräftas via Process:% Privileged Time (sqlservr-objekt) och även Windows Task Manager eller Process Explorer.
Även om problem med hög kärntid borde vara sällsynta, kräver de fortfarande andra felsökningsvägar än vanliga CPU-felsökningsproblem. Några potentiella orsaker till hög kärntid inkluderar felaktiga filterdrivrutiner (antivirus, krypteringstjänster), inaktuella eller saknade firmwareuppdateringar och drivrutiner, eller defekta I/O-komponenter.
Identifiera CPU-konsumenter
När du väl har validerat vilken SQL Server-instans som driver användarens CPU-användning på systemet, finns det massor av förbeställda frågeexempel ute på webben som du kan använda.
Nedan finns en lista över DMV:er som människor vanligtvis använder i olika former under ett prestandaproblem. Jag strukturerade detta i ett fråge- och svarsformat för att hjälpa dig att förstå varför du skulle vilja komma åt dem.
- sys.dm_exec_requests
- sys.dm_exec_sql_text
- sys.dm_exec_sessions
- sys.dm_exec_connections
- sys.dm_exec_query_plan
- sys.dm_os_waiting_tasks
- sys.dm_exec_query_stats
- Aggregera efter total_worker_time
- Definiera medelvärden med execution_count
- Om ad hoc-arbetsbelastningar kan grupperas efter query_hash
- Använd plan_handle med sys.dm_exec_query_plan för att ta tag i planen
- sys.dm_os_tasks
- Beställt efter session_id, request_id
- sys.dm_exec_query_plan
- Titta på planoperatörer – men kom ihåg att detta bara är den beräknade planen
- sys.dm_exec_query_stats
- Filtrera total_elapsed_time mindre än total_worker_time
- Men observera att detta kan vara ett falskt negativt för blockeringsscenarier – där varaktigheten är uppblåst på grund av en väntan på resurs
Vilka förfrågningar körs just nu och vad är deras status?
Vad kör den?
Var kommer den ifrån?
Vad är dess beräknade plan? (men var försiktig med att strimla xml på ett redan CPU-begränsat system)
Vem väntar på en resurs och vad väntar de på?
Vilka frågor har tagit mest CPU-tid sedan den senaste omstarten?
Använder den här frågan parallellism?
Mata mönstret och lös ut
Du skrattar förmodligen åt just detta steg – eftersom det här kan vara det mest involverade (och är ytterligare en anledning till varför SQL Server-proffs är förvärvsarbetande). Det finns flera olika mönster och associerade upplösningar – så jag avslutar det här inlägget med en lista över de vanligaste drivrutinerna för CPU-prestandaproblem som jag har sett under de senaste åren:
- Höga I/O-operationer (och enligt min erfarenhet är detta den vanligaste drivrutinen för CPU)
- Problem med uppskattning av kardinalitet (och tillhörande dålig kvalitet på frågeplanen)
- Oväntad parallellism
- Överdriven kompilering/omkompilering
- Beräkningsintensiva UDF-anrop, fragmenteringsoperationer
- Rad för plågsamma radoperationer
- Samtidiga underhållsaktiviteter (t.ex. UPPDATERA statistik med FULLSCAN)
Varje område jag har identifierat har ett stort tillhörande arbete att undersöka. När det gäller konsoliderade resurser tror jag fortfarande att en av de bättre fortfarande är den tekniska artikeln "Felsökning av prestandaproblem i SQL Server 2008" skriven av Sunil Agarwal, Boris Baryshnikov, Keith Elmore, Juergen Thomas, Kun Cheng och Burzin Patel.
Sammanfattning
Som med alla metoder finns det gränser för dess användning och områden där det är motiverat att improvisera. Observera att jag inte föreslår att stegen som jag beskrev i det här inlägget ska användas som en stel ram, utan istället anser att det är en startpunkt för dina felsökningsinsatser. Även mycket erfarna SQL Server-proffs kan göra nybörjarmisstag eller vara partiska av sina senaste felsökningserfarenheter, så att ha en minimal metod kan hjälpa till att undvika felsökning av fel problem.