I dette indlæg vil jeg diskutere en generel metode til fejlfinding af CPU-ydeevneproblemer. Jeg kan godt lide at anvende metoder som standard, og jeg kan også godt lide at opbygge effektivitet i, hvordan jeg fejlfinder problemer baseret på tidligere erfaringer. Uden generelle rammer bliver det for nemt at gå glip af den sande rodårsag midt i en krise.
De trin, jeg vil beskrive i dette indlæg, er som følger:
- Definer problemet
- Valider de nuværende betingelser
- Svar "Er det SQL Server"?
- Identificer CPU-forbrugere
- Samstem mønsteret og afgør
Denne artikel vil dække hvert af disse trin. Jeg vil antage, at du muligvis ikke bruger et tredjepartsovervågningsværktøj. Hvis du dog er det, gælder rammerne her stadig, men dine datakilder og værktøjer til din rådighed vil variere fra det, jeg beskriver.
Definer problemet
Først skal vi undersøge problemet. Når nogen kommer op til dig og siger, at de ser et CPU-ydelsesproblem, kan det betyde en række forskellige ting. Så den første opgave er at forstå, hvad karakteren af CPU-ydelsesproblemet i øjeblikket er.
Nogle almindelige kategorier omfatter:
- Tilgængeligheden påvirkes på grund af "tilknyttede CPU'er". For eksempel – alle skemalæggere, der kører 100 % over hele linjen, og gennemløbet er gået i stå eller reduceret væsentligt.
- Forringelse af ydeevne på grund af "højere end normalt" CPU-brug. Så vi er ikke bundet, men dine CPU'er kører med en højere procentdel end normalt, og det påvirker formentlig ydeevnen.
- En anden almindelig kategori af CPU-ydeevneproblemer er "vindere og tabere", hvor arbejdsbelastninger konkurrerer mod hinanden. Måske har du en OLTP-arbejdsbelastning, der oplever reduceret gennemløb på grund af en parallel eksekverende rapportforespørgsel.
- Et andet problem kan være at støde på et vippepunkt – hvor dit systems overordnede kapacitets- og skalerbarhedsbegrænsninger rammes på et bestemt tidspunkt.
Jeg nævner disse overordnede kategorier som udgangspunkt, men jeg ved, at der ofte kan være store afhængigheder på tværs af disse problemstillinger, og den ene kategorisering kan blande sig i den anden. Når det er sagt, er det første skridt at definere symptomerne og problemerne så klart som muligt.
Valider de nuværende betingelser
Uanset om problemet er sket i fortiden eller sker lige nu, er det vigtigt at få så meget baggrundsinformation om systemet, arbejdsbyrden og konfigurationer som muligt. Hvis du bruger baselines og run-books, sporer du ideelt set allerede mange af disse oplysninger. Hvis ikke, så spørg dig selv, hvor hurtigt du kunne få svar på disse spørgsmål kl. 02.00 midt i en krise.
Følgende underafsnit dækker vigtige datapunkter, som jeg typisk er interesseret i for et problem med CPU-ydelse.
- Hvor mange stikkontakter og kerner?
- Er hyper-threading aktiveret?
- Hvad er processormodellen, arkitekturen (32-bit/64-bit)?
- Er dette en virtuel gæst?
- Hvis det er tilfældet, vil du nu også være interesseret i detaljer om værten og de andre virtuelle gæster, du deler ressourcer med.
- Er der nogen CPU-relaterede indstillinger i kraft?
- For eksempel Hyper-V CPU
- Hvor mange vCPU'er er tildelt på tværs af gæster?
- Hvor mange vCPU'er har denne gæst?
- Blev gæsten for nylig migreret til en ny vært før problemet?
- Maksimal grad af parallelitet indstilling
- Omkostningsgrænse for mulighed for parallelitet
- Processoraffinitetsindstilling
- Indstilling for prioritet boost
- Indstilling for maks. arbejdstråde
- Letvægts pooling-indstilling
- Hvad er indstillingen for strømstyring? (OS-niveau, VM Host eller BIOS kontrolleret)
- Høj ydeevne, afbalanceret, strømbesparende?
- Er det konfigureret ud over standardindstillingerne?
- Ser du nogle usædvanlige advarsler eller fejl?
Fysiske serveroplysninger
Virtuelle serveroplysninger
Reserve, VMware CPU reservation, Hyper-V CPU relativ vægt og VMware CPU Shares.
SQL Server-instanskonfigurationsindstillinger
De første tre konfigurationer kan kræve yderligere diskussion. Der er sjældent absolutte værdier vedrørende disse indstillinger.
Med hensyn til de sidste tre indstillinger, såsom "prioritetsboost", hvis jeg ser, at de er på ikke-standardværdier, vil jeg helt sikkert presse på for mere baggrundsinformation og historie.
Indstillinger for CPU-strømoption
Power-option-indstillinger under "Høj ydeevne" er stadig meget almindelige og bør ikke ignoreres for servere, der hoster SQL Server-instanser.
Resource Governor-konfiguration
Jeg synes stadig, at det er sjældent at støde på kunder, der overhovedet bruger denne funktion, men det er nemt at validere, om det bliver brugt, og det vil være det værd i de gange, det faktisk er konfigureret ud over standarden.
SQL Server fejllog og Windows hændelseslogfiler
Hvorfor kigge i fejl- og hændelsesloggene for et CPU-problem? Nogle gange kan upstream-problemer forårsage downstream-ydeevneproblemer i SQL Server. Du ønsker ikke at spilde tid på at tune en forespørgsel eller tilføje et nyt indeks, når du er opstrøms rodårsagsproblemet er et problem med hardwarekomponentnedbrydning.
Svar "Er det SQL Server?"
Det lyder indlysende, når jeg spørger det, men du vil virkelig ikke bruge en betydelig mængde tid på at fejlfinde et problem med høj CPU i SQL Server, hvis synderen faktisk ikke er SQL Server.
Brug i stedet et hurtigt øjeblik på at tjekke, hvilken proces der bruger mest CPU. Der er flere muligheder at vælge imellem, herunder:
- Proces:% brugertid (brugertilstand)
- Proces:% privilegeret tid (kernetilstand)
- Task Manager
- Process Explorer
- Seneste CPU-oplysninger via sys.dm_os_ring_buffers eller systemsundhedssessionen for de specifikke SQL Server-forekomster, der kører på systemet
Hvis det er SQL Server, og du har flere SQL Server-instanser at vælge imellem, skal du være sikker på, at du fejlfinder den rigtige SQL Server-instans på værten. Der er et par måder at gøre dette på, herunder brugen af SELECT SERVERPROPERTY('processid') for at hente PID'et og derefter knytte det til Task Manager eller Process Explorer.
Når du har bekræftet, at det er SQL Server, ser du så høj brugertid eller privilegeret (kerne) tid? Igen kan dette bekræftes via Process:% Privileged Time (sqlservr-objekt) og også Windows Task Manager eller Process Explorer.
Selvom problemer med høj kernetid burde være sjældne, kræver de stadig andre fejlfindingsstier end CPU-fejlfindingsproblemer med standardbrugertid. Nogle potentielle årsager til høj kernetid omfatter defekte filterdrivere (antivirus, krypteringstjenester), forældede eller manglende firmwareopdateringer og drivere eller defekte I/O-komponenter.
Identificer CPU-forbrugere
Når du har valideret, hvilken SQL Server-instans der driver brugerens CPU-brug på systemet, er der masser af præ-canned forespørgselseksempler på nettet, som du kan bruge.
Nedenfor er en liste over DMV'er, som folk almindeligvis bruger i forskellige former under et præstationsproblem. Jeg strukturerede dette i et Q&A-format for at hjælpe med at forstå, hvorfor du ønsker at få adgang til 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
- Aggregér efter total_worker_time
- Definer gennemsnit med execution_count
- Hvis ad hoc-arbejdsbelastninger, kan du gruppere efter query_hash
- Brug plan_handle med sys.dm_exec_query_plan for at få fat i planen
- sys.dm_os_tasks
- Bestilt efter session_id, request_id
- sys.dm_exec_query_plan
- Se på planoperatører – men husk, at dette kun er den anslåede plan
- sys.dm_exec_query_stats
- Filtrer total_elapsed_time mindre end total_worker_time
- Men bemærk, at dette kan være en falsk negativ for blokeringsscenarier – hvor varigheden er oppustet på grund af ventetid på ressource
Hvilke anmodninger udføres lige nu, og hvad er deres status?
Hvad udfører den?
Hvor er det fra?
Hvad er dens anslåede plan? (men vær forsigtig med at makulere xml på et allerede CPU-begrænset system)
Hvem venter på en ressource, og hvad venter de på?
Hvilke forespørgsler har brugt mest CPU-tid siden sidste genstart?
Bruger denne forespørgsel parallelisme?
Match mønsteret, og afgør
Du griner sikkert af dette særlige trin - da dette kan være det mest involverede (og er endnu en grund til, at SQL Server-professionelle er lønmodtagere). Der er flere forskellige mønstre og tilknyttede opløsninger – så jeg afslutter dette indlæg med en liste over de mere almindelige drivere til CPU-ydelsesproblemer, som jeg har set i løbet af de sidste par år:
- Høj I/O-operationer (og efter min erfaring er dette den mest almindelige driver til CPU)
- Problemer med kardinalitetsestimater (og tilhørende dårlig forespørgselsplankvalitet)
- Uventet parallelitet
- Overdreven kompilering/genkompilering
- Beregningsintensive UDF-opkald, makuleringsoperationer
- Række-for-pinefulde rækkehandlinger
- Samtidige vedligeholdelsesaktiviteter (f.eks. OPDATERING af statistik med FULLSCAN)
Hvert område, jeg har identificeret, har et stort tilknyttet arbejde at forske i. Med hensyn til konsoliderede ressourcer tror jeg stadig, at en af de bedre stadig er den tekniske artikel "Fejlfinding af ydeevneproblemer i SQL Server 2008" skrevet af Sunil Agarwal, Boris Baryshnikov, Keith Elmore, Juergen Thomas, Kun Cheng og Burzin Patel.
Oversigt
Som med enhver metode er der grænser for dens anvendelse og områder, hvor du er berettiget til at improvisere. Bemærk venligst, at jeg ikke foreslår, at de trin, jeg beskrev i dette indlæg, skal bruges som en stiv ramme, men i stedet betragter det som et startpunkt for din fejlfindingsindsats. Selv meget erfarne SQL Server-professionelle kan lave nybegyndere fejl eller være forudindtaget af deres nyere fejlfindingserfaringer, så at have en minimal metodik kan hjælpe med at undgå fejlfinding af det forkerte problem.