Problemen met SQL Server CPU-prestaties oplossen

In dit bericht bespreek ik een algemene methode voor het oplossen van problemen met de CPU-prestaties. Ik hou ervan om standaard methodologieën toe te passen en ik hou er ook van om efficiëntie te creëren in de manier waarop ik problemen oplos op basis van ervaringen uit het verleden. Zonder een algemeen kader wordt het te gemakkelijk om midden in een crisis de ware oorzaak over het hoofd te zien.

De stappen die ik in dit bericht zal beschrijven zijn als volgt:

1. Definieer het probleem
2. Valideer de huidige voorwaarden
3. Antwoord "Is het SQL Server"?
4. Identificeer CPU-consumenten
5. Overeenkomen met het patroon en oplossen

Dit artikel behandelt elk van deze stappen. Ik ga ervan uit dat u mogelijk geen monitoringtool van derden gebruikt. Als je dat wel bent, is het raamwerk hier nog steeds van toepassing, maar de gegevensbronnen en tools die je tot je beschikking hebt, zullen verschillen van wat ik beschrijf.

Definieer het probleem

Eerst moeten we het probleem in kaart brengen. Wanneer iemand naar je toe komt en zegt dat ze een probleem met de CPU-prestaties zien, kan dit een aantal verschillende dingen betekenen. Dus de eerste taak is om te begrijpen wat de aard van het CPU-prestatieprobleem momenteel is.

Enkele veelvoorkomende categorieën zijn:

• Beschikbaarheid wordt beïnvloed door 'gekoppelde CPU's'. Bijvoorbeeld:alle planners draaien over de hele linie op 100% en de doorvoer loopt vast of wordt aanzienlijk verminderd.
• Verslechtering van de prestaties door 'hoger dan normaal' CPU-gebruik. We zijn dus niet gekoppeld, maar uw CPU's werken met een hoger percentage dan normaal en vermoedelijk heeft dit invloed op de prestaties.
• Een andere veelvoorkomende categorie van problemen met CPU-prestaties is het scenario van 'winnaars en verliezers', waarbij workloads met elkaar concurreren. Misschien heeft u een OLTP-werkbelasting die een verminderde doorvoer ondervindt vanwege een parallel uitgevoerde rapportquery.
• Een ander probleem kan het tegenkomen van een omslagpunt zijn - waar de algehele capaciteit en schaalbaarheidsbeperkingen van uw systeem op een bepaald punt worden geraakt.

Ik noem deze overkoepelende categorieën als uitgangspunt, maar ik weet dat er vaak grote afhankelijkheden kunnen zijn tussen deze problemen en de ene categorie kan in de andere opgaan. Dat gezegd hebbende, is de eerste stap om de symptomen en problemen zo duidelijk mogelijk te definiëren.

Valideer de huidige voorwaarden

Of het probleem zich nu in het verleden heeft voorgedaan of zich nu voordoet, het is belangrijk om zoveel mogelijk achtergrondinformatie te krijgen over het systeem, de werkbelasting en de configuraties. Als u baselines en runbooks gebruikt, houdt u idealiter al veel van deze informatie bij. Zo niet, vraag uzelf dan af hoe snel u midden in een crisis om 2 uur 's nachts antwoord op deze vragen zou kunnen krijgen.

De volgende subsecties behandelen belangrijke gegevenspunten waarin ik doorgaans geïnteresseerd ben voor een CPU-prestatieprobleem.

Fysieke serverdetails

• Hoeveel sockets en cores?
• Is hyperthreading ingeschakeld?
• Wat is het processormodel, de architectuur (32-bit/64-bit)?

Virtuele serverdetails

• Is dit een virtuele gast?
• Als dat zo is, ben je nu ook geïnteresseerd in details over de host en de andere virtuele gasten waarmee je bronnen deelt.
• Zijn er CPU-gerelateerde instellingen van kracht?
• Bijvoorbeeld Hyper-V CPU

Reserveren, VMware CPU-reservering, Hyper-V CPU-relatief gewicht en VMware CPU-shares.

• Hoeveel vCPU's zijn toegewezen aan gasten?
• Hoeveel vCPU's heeft deze gast?
• Is de gast onlangs gemigreerd naar een nieuwe host voorafgaand aan het probleem?

Configuratie-instellingen SQL Server-instantie

• Maximale mate van parallellisme-instelling
• Kostendrempel voor optie parallellisme
• Instelling processoraffiniteit
• Instelling prioriteitsboost
• Instelling Max. worker-threads
• Instelling voor lichtgewicht poolen


De eerste drie configuraties vereisen mogelijk verdere bespreking. Er zijn zelden absolute waarden over deze instellingen.

Wat betreft de laatste drie instellingen, zoals "prioriteitsboost", als ik zie dat ze niet-standaardwaarden hebben, ga ik zeker aandringen op meer achtergrondinformatie en geschiedenis.

CPU power-optie-instellingen

• Wat is de instelling voor de aan/uit-optie? (OS-niveau, VM-host of BIOS-gestuurd)
  • Hoge prestaties, gebalanceerd, energiebesparend?

Instellingen voor energiebeheer onder 'Hoge prestaties' zijn nog steeds heel gebruikelijk en mogen niet worden genegeerd voor servers die SQL Server-instanties hosten.

Configuratie van bronbeheer

• Is het geconfigureerd buiten de standaardinstellingen?


Ik vind nog steeds dat het zeldzaam is om klanten tegen te komen die deze functie gebruiken, maar het is gemakkelijk te valideren of het wordt gebruikt en het is de moeite waard voor de keren dat het daadwerkelijk is geconfigureerd buiten de standaardinstellingen.

SQL Server-foutlogboek en Windows-gebeurtenislogboeken

• Zie je ongebruikelijke waarschuwingen of fouten?


Waarom in de fouten- en gebeurtenislogboeken zoeken naar een CPU-probleem? Soms kunnen stroomopwaartse problemen leiden tot prestatieproblemen in SQL Server. U wilt geen tijd verspillen aan het afstemmen van een zoekopdracht of het toevoegen van een nieuwe index wanneer het hoofdoorzaakprobleem een ​​probleem is met degradatie van hardwarecomponenten.

Antwoord "Is het SQL Server?"

Het klinkt voor de hand liggend als ik het vraag, maar je wilt echt niet veel tijd besteden aan het oplossen van een hoog CPU-probleem in SQL Server als de boosdoener niet echt SQL Server is.

Neem in plaats daarvan even de tijd om te controleren welk proces de meeste CPU verbruikt. Er zijn verschillende opties om uit te kiezen, waaronder:

• Proces:% gebruikerstijd (gebruikersmodus)
• Proces:% geprivilegieerde tijd (kernelmodus)
• Taakbeheer
• Procesverkenner
• Recente CPU-informatie via sys.dm_os_ring_buffers of de systeemgezondheidssessie voor de specifieke SQL Server-instanties die op het systeem worden uitgevoerd

Als het SQL Server is en u meerdere SQL Server-instanties hebt om uit te kiezen, zorg er dan voor dat u de juiste SQL Server-instantie op de host oplost. Er zijn een paar manieren om dit te doen, waaronder het gebruik van SELECT SERVERPROPERTY('processid') om de PID te krijgen en deze vervolgens te koppelen aan Taakbeheer of Process Explorer.
Zodra u hebt bevestigd dat het SQL Server is, ziet u dan veel gebruikerstijd of geprivilegieerde (kernel) tijd? Nogmaals, dit kan worden bevestigd via Process:% Privileged Time (sqlservr-object) en ook via Windows Taakbeheer of Process Explorer.

Hoewel problemen met hoge kerneltijd zeldzaam zouden moeten zijn, vereisen ze toch andere paden voor probleemoplossing dan standaard CPU-probleemoplossingsproblemen voor gebruikers. Enkele mogelijke oorzaken van een hoge kerneltijd zijn onder meer defecte filterstuurprogramma's (antivirus-, encryptieservices), verouderde of ontbrekende firmware-updates en stuurprogramma's, of defecte I/O-componenten.

Identificeer CPU-consumenten

Als u eenmaal hebt gevalideerd welke SQL Server-instantie het CPU-gebruik in de gebruikerstijd op het systeem aanstuurt, zijn er tal van vooraf ingeblikte queryvoorbeelden op internet die u zou kunnen gebruiken.

Hieronder vindt u een lijst met DMV's die mensen vaak gebruiken in verschillende vormen tijdens een prestatieprobleem. Ik heb dit gestructureerd in een Q&A-indeling om te helpen bepalen waarom je ze zou willen openen.

Welke verzoeken worden momenteel uitgevoerd en wat is hun status?

• sys.dm_exec_requests

Wat voert het uit?

• sys.dm_exec_sql_text

Waar komt het vandaan?

• sys.dm_exec_sessions
• sys.dm_exec_connections

Wat is het geschatte plan? (maar pas op voor het versnipperen van xml op een systeem met al CPU-beperkingen)

• sys.dm_exec_query_plan

Wie wacht er op een hulpbron en waar wachten ze op?

• sys.dm_os_waiting_tasks

Welke zoekopdrachten hebben de meeste CPU-tijd in beslag genomen sinds de laatste herstart?

• sys.dm_exec_query_stats
• Totaal op total_worker_time
• Definieer gemiddelden met execution_count
• Als ad hoc werklasten, kunt u groeperen op query_hash
• Gebruik de plan_handle met sys.dm_exec_query_plan om het plan te pakken

Gebruikt deze zoekopdracht parallellisme?

• sys.dm_os_tasks
  • Besteld door session_id, request_id
• sys.dm_exec_query_plan
  • Kijk naar plan-operators – maar onthoud dat dit slechts het geschatte plan is
• sys.dm_exec_query_stats
  • Filter total_elapsed_time minder dan total_worker_time
  • Maar houd er rekening mee dat dit een vals-negatief kan zijn voor blokkeringsscenario's - waarbij de duur te hoog is vanwege het wachten op de bron

Overeenkomen met het patroon en oplossen

Je lacht waarschijnlijk om deze specifieke stap - omdat deze de meest betrokken kan zijn (en een andere reden is waarom SQL Server-professionals betaald werk hebben). Er zijn verschillende patronen en bijbehorende resoluties - dus ik zal dit bericht afsluiten met een lijst met de meest voorkomende stuurprogramma's voor CPU-prestaties die ik de afgelopen jaren heb gezien:

• Hoge I/O-bewerkingen (en in mijn ervaring is dit de meest voorkomende driver van CPU)
• Problemen met kardinaliteitsschattingen (en de bijbehorende slechte kwaliteit van het queryplan)
• Onverwacht parallellisme
• Overmatige compilatie / hercompilatie
• Rekenintensieve UDF-oproepen, vernietigingsoperaties
• Rij-voor-pijnlijke rijbewerkingen
• Gelijktijdige onderhoudsactiviteiten (bijv. UPDATE-statistieken met FULLSCAN)

Elk gebied dat ik heb geïdentificeerd, heeft een groot bijbehorend oeuvre om te onderzoeken. Wat de geconsolideerde bronnen betreft, denk ik nog steeds dat een van de betere het technische artikel "Troubleshooting Performance Problems in SQL Server 2008" is, geschreven door Sunil Agarwal, Boris Baryshnikov, Keith Elmore, Juergen Thomas, Kun Cheng en Burzin Patel.

Samenvatting

Zoals bij elke methodologie, zijn er grenzen voor het gebruik ervan en gebieden waar improvisatie gerechtvaardigd is. Houd er rekening mee dat ik niet suggereer dat de stappen die ik in dit bericht heb beschreven, worden gebruikt als een rigide raamwerk, maar dat het in plaats daarvan een startpunt is voor uw inspanningen om problemen op te lossen. Zelfs zeer ervaren SQL Server-professionals kunnen beginnersfouten maken of bevooroordeeld zijn door hun recentere ervaringen met het oplossen van problemen, dus een minimale methodologie kan helpen voorkomen dat het verkeerde probleem wordt opgelost.