SQL SERVER CU5: Fixes CPU starvation issues
Before we dive into today's topic, if you missed my previous post you can take a look at SQL SERVER CU5: Bug Reference 5131003, Fixes an XML External Entity (XXE) vulnerability in the Web Service Task. 👉 If you found this deep-dive helpful, feel free to check out the ads—your support helps me keep creating high-quality SQL Server content for the community.
💣 SQL SERVER CU5: Big Reference 5157138 Fixes CPU Starvation Issues During In-Memory OLTP Garbage Collection
SQL Server CU5 quietly fixes a dangerous CPU starvation scenario inside In-Memory OLTP hash index garbage collection scans.
⚡ If your server suddenly spikes CPU with Hekaton workloads, this is one CU you absolutely do NOT want to ignore.
🧠 TL;DR
✔️ SQL Server CU5 fixes CPU starvation during In-Memory OLTP hash index garbage collection
✔️ The engine now adds scheduler yields at regular intervals during long-running scans 🛠️
✔️ This prevents workers from monopolizing CPU schedulers under heavy memory-optimized workloads 🚀
✔️ Systems using hash indexes in Hekaton environments are the most impacted 💣
🚀 The Hook
In this post, I’ll show you why SQL Server CU5 introduces one of the most important scheduler fairness fixes for In-Memory OLTP environments.
⚡ If you use memory-optimized tables and hash indexes, this fix can directly reduce CPU starvation, SOS scheduler pressure, and unpredictable latency spikes.
Hi SQL SERVER Guys and Gals,
One of the most dangerous SQL Server performance problems is not high CPU itself.
💣 It is CPU starvation.
That means some workers consume schedulers for too long while other requests wait excessively.
And this is exactly what Microsoft addressed in SQL Server CU5 with fix reference 5157138.
🧠 What This Fix Really Means
The fix targets the internal garbage collection mechanism used by In-Memory OLTP (Hekaton).
Specifically:
- Memory-optimized tables using hash indexes
- Garbage collection scans running too long without yielding
- CPU schedulers becoming monopolized
- Other workers waiting excessively
⚡ CU5 now introduces regular scheduler yields during these scans.
This improves fairness between workers and reduces starvation scenarios.
💣 Why CPU Starvation Is Dangerous
Many DBAs look only at total CPU percentage.
That is a mistake.
A server can show:
- Moderate CPU usage
- But terrible latency
- High SOS scheduler waits
- Slow logins
- Query timeouts
- Worker starvation
⚡ Long-running internal engine tasks without cooperative yielding can create exactly this behavior.
🔍 DIAGNOSIS
If you suspect scheduler pressure related to memory-optimized workloads, start here:
-- 🔍 CPU Diagnostic Query
SELECT
scheduler_id,
cpu_id,
current_tasks_count,
runnable_tasks_count,
active_workers_count,
load_factor
FROM sys.dm_os_schedulers
WHERE status = 'VISIBLE ONLINE';
💣 High runnable_tasks_count can indicate scheduler pressure or worker starvation.
🧪 QUERY
You should also identify memory-optimized objects and hash indexes.
-- 🧪 In-Memory OLTP Hash Indexes
SELECT
t.name AS table_name,
i.name AS index_name,
i.type_desc,
i.bucket_count
FROM sys.hash_indexes i
INNER JOIN sys.tables t
ON i.object_id = t.object_id;
⚡ Large bucket counts and high churn workloads can increase garbage collection activity.
🧠 What Is Happening Internally?
In-Memory OLTP uses optimistic concurrency and versioned rows.
Deleted or obsolete row versions must eventually be cleaned.
This cleanup process is handled by internal garbage collection mechanisms.
Before CU5:
- Hash index scans could run for extended periods
- Workers could hold schedulers too long
- Cooperative scheduling fairness degraded
After CU5:
- SQL Server inserts periodic yields
- Schedulers regain fairness
- Other workers get CPU opportunities sooner
🚀 My REAL Strategy
In real production systems, I NEVER evaluate only raw CPU percentages.
⚡ I always correlate:
- SOS scheduler waits
- Runnable queue length
- Memory-optimized workload activity
- Worker starvation symptoms
- Latency spikes
💣 Many "random" performance spikes in Hekaton environments are actually scheduler fairness problems.
My recommendation:
- Apply CU5 if you use In-Memory OLTP heavily
- Monitor runnable_tasks_count continuously
- Validate hash index bucket sizing
- Avoid excessive over-allocation of bucket_count
- Watch for internal garbage collection pressure
📊 TAKEAWAY
This CU5 fix is NOT just another minor patch note.
⚡ It directly impacts scheduler fairness in SQL Server Engine internals.
For systems using:
- Memory-optimized tables
- Hash indexes
- High-concurrency OLTP workloads
- Heavy transactional ingestion
...this can be the difference between stable latency and random production slowdowns.
📚 Official References
📢 Support the Blog: Did you find this deep-dive helpful? The ads you see here are selected to reflect your interests. If a partner's offer catches your eye, give it a look! Your engagement helps me continue publishing premium SQL Server content for the community.
Performance Tuning Knowledge Hub
Everything you need to master SQL Server, all in one place.
Comments
Post a Comment