High CPU spikes, often from unoptimized queries or parallelism, are a common search as they cause app slowdowns in multi-user environments.
Scenario: A financial app's reporting module pegs CPU at 90% during end-of-day processing, delaying transactions.
Detailed Solution with Code Examples:
- Step 1: Monitor CPU. Use Performance Monitor (PerfMon) or DMVs:
If runnable_tasks_count >0, there's CPU pressure.sqlSELECTscheduler_id,current_tasks_count,runnable_tasks_count,current_workers_count,active_workers_count,work_queue_count,pending_disk_io_countFROM sys.dm_os_schedulersWHERE scheduler_id < 255;
- Step 2: Find Top CPU-Consuming Queries.
sqlSELECT TOP 10qs.total_worker_time / qs.execution_count AS avg_worker_time,qs.execution_count,qt.text AS query_text,DB_NAME(qt.dbid) AS database_nameFROM sys.dm_exec_query_stats qsCROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) qtORDER BY qs.total_worker_time DESC;
- Step 3: Address Parameter Sniffing or Bad Plans. Add OPTION (RECOMPILE):
sqlSELECT * FROM YourTable WHERE Column = @Param OPTION (RECOMPILE);
- Step 4: Tune Parallelism. Check and adjust MAXDOP:
sqlEXEC sp_configure 'show advanced options', 1;RECONFIGURE;EXEC sp_configure 'max degree of parallelism', 4; -- Set to number of cores/2 for OLTPRECONFIGURE;
- Step 5: Clear Plan Cache Selectively.
sqlDECLARE @PlanHandle VARBINARY(64);SELECT @PlanHandle = qs.plan_handleFROM sys.dm_exec_query_stats qsCROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) qtWHERE qt.text LIKE '%YourQuery%';DBCC FREEPROCCACHE(@PlanHandle);
Best Practices:
- Set cost threshold for parallelism to 50+ to avoid parallel plans for simple queries.
- Use Resource Governor to limit CPU for specific workloads.
- Update to SQL Server 2025 for better adaptive query processing.
- Monitor signal waits; if >25% of total waits, it's CPU-bound.
- In cloud environments like Azure SQL, scale up vCores temporarily.
Fixing this prevents outages, keeping CPU under 70% during peaks.
No comments:
Post a Comment
Thanks for your valuable comment...........
Md. Mominul Islam