SQL Server CPU op 100 procent is een symptoom, geen oorzaak. Het kan een runaway-query zijn, een onverwachte parallel-explosie, een spinlock-storm of simpelweg te weinig vCores voor de workload. Onze freelance MSSQL DBA's gaan nooit blind throttlen voordat de oorzaak helder is.
De top CPU-consumer vinden
sys.dm_exec_query_stats gesorteerd op total_worker_time of max_worker_time per execution toont de queries die het meeste rekenwerk doen. Vaak is het één query die 80 procent verbrandt. De plan_handle koppelen aan sys.dm_exec_query_plan en sys.dm_exec_sql_text geeft direct de tekst en het plan.
Parallellisme en CXPACKET-waits
Hoge CXPACKET-waits met hoge CPU wijzen op een query die alle vCores claimt. MAXDOP en cost threshold for parallelism op instance-niveau zijn de stompe ingrepen. Beter is per-query OPTION (MAXDOP n) of een Query Store-plan-fix. Sinds 2016 is MAXDOP per database-scoped configuration mogelijk, wat meer chirurgie geeft.
Spinlocks en hot pages
Op moderne servers met veel cores ziet u soms spinlock-contentie op LOCK_HASH of SOS_CACHESTORE. sys.dm_os_spinlock_stats laat zien welke spinlocks domineren. Dit is een NUMA- of workload-vraagstuk, geen query-vraagstuk. We kijken naar trace flag 8048 (in 2014 standaard), processor affinity en NUMA-node-binding.
Plan regression na update of patch
Als CPU plotseling spikete na een Cumulative Update, een statistics-refresh of een tabel-modificatie, is het bijna altijd een plan regression. Query Store toont in een grafiek welke queries plotseling andere planhashes draaien. Force het oude plan en u heeft tijd om duurzaam te fixen.
Of toch gewoon te weinig CPU
Niet elke 100 procent is een bug. Een SSAS-cube-refresh, een DBCC CHECKDB op een 4TB-database, of een geplande ETL kan terecht alle vCores gebruiken. We onderscheiden geplande van ongeplande pieken voordat we vCores erbij kopen of de workload verschuiven.
Verwant: Freelance SQL DBA, Trage query oplossen.