SQL Server 2025 CU3 – The Hidden Performance Fix Nobody Talks About (False Sharing Benchmark)

SQL Server 2025 CU3 – Does It REALLY Fix CPU Contention? Let’s Benchmark It 🔥

Hi SQL SERVER Guys,

Today... we go serious.

No theory. No assumptions. No marketing.

👉 Just tests, numbers and benchmarks.

We are going to validate one of the most interesting fixes introduced in SQL Server 2025 CU3:

"Reduces CPU contention on high-core servers by fixing cache line conflicts (false sharing), improving overall scalability."

(If you missed it, check my full CU3 breakdown here 👇)

👉 SQL Server 2025 CU3 – Critical Fixes You Should NOT Ignore

🎯 Benchmark Goal

We want to verify if CU3 really reduces:

  • CPU contention
  • Spinlocks / latch contention
  • Scalability issues on multi-core systems

👉 In short: parallel workload scalability

⚠️ The Real Problem: False Sharing

The bug is related to:

👉 false sharing so when:

  • multiple CPU cores writing on the same cache line
  • continuous cache invalidations
  • massive performance degradation

This typically this happens with:

  • high concurrency workloads
  • shared engine structures
  • columnstore-heavy operations

🧪 Test Strategy

Scenario Version
Test 1 post CU2
Test 2 Post CU3

🔥 STEP 1 – Build a Serious Dataset

DROP TABLE IF EXISTS BigTable;

CREATE TABLE BigTable
(
    id INT IDENTITY(1,1),
    c1 INT,
    c2 INT,
    c3 CHAR(200)
);

INSERT INTO BigTable (c1,c2,c3)
SELECT TOP 5000000
    ABS(CHECKSUM(NEWID())),
    ABS(CHECKSUM(NEWID())),
    REPLICATE('X',200)
FROM sys.objects a
CROSS JOIN sys.objects b
CROSS JOIN sys.objects c;

👉 We need volume + memory pressure

🔥 STEP 2 – CPU Heavy Query

SELECT SUM(c1), SUM(c2)
FROM BigTable
WHERE c1 % 10 = 0;

👉 The WHERE clause made the query Non-SARGable (if you miss my post about it: SQL SERVER! SARGability: the One Concept You Absolutely Must Understand!) → this forces CPU work

🔥 STEP 3 – Parallel Stress (CRITICAL)

Open 1 sessions , run and add other session until we have 100 sessions!

SELECT SUM(c1), SUM(c2)
FROM BigTable
WHERE c1 % 10 = 0;

👉 This creates:

  • high concurrency
  • CPU pressure
  • real contention

📊 STEP 4 – What to Measure

We will measure the following parameters:

1. CPU Pressure

SELECT TOP 10 *
FROM sys.dm_os_schedulers
ORDER BY runnable_tasks_count DESC;

👉 Look at:

  • runnable_tasks_count
  • load_factor

2. Spinlock Contention 🔥

SELECT *
FROM sys.dm_os_spinlock_stats
WHERE collisions > 0
ORDER BY collisions DESC;

3. Wait Stats

SELECT *
FROM sys.dm_os_wait_stats
ORDER BY wait_time_ms DESC;

Focus on:

  • SOS_SCHEDULER_YIELD
  • CXPACKET / CXCONSUMER

4. Real CPU Usage

SELECT 
    record.value('(./Record/SchedulerMonitorEvent/SystemHealth/SystemIdle)[1]', 'int') AS Idle,
    record.value('(./Record/SchedulerMonitorEvent/SystemHealth/ProcessUtilization)[1]', 'int') AS SQLCPU
FROM 
(
    SELECT CONVERT(XML, record) AS record
    FROM sys.dm_os_ring_buffers
    WHERE ring_buffer_type = 'RING_BUFFER_SCHEDULER_MONITOR'
) x;

📈 STEP 5 – Expected Results

If this patch do not lie we will expect:

✅ SQL Server 2025 CU2

  • High CPU but inefficient
  • Heavy spinlock contention
  • Poor scaling with more threads

✅ SQL Server 2025 CU3

  • More stable CPU usage
  • Reduced contention
  • Better scalability with concurrency

👉 This is the key point:

But it’s not just about speed… it’s about SCALABILITY.

🧠 Advanced Test. Using columnstore indexes

To push the benchmark even further, we will repeat the entire test using Columnstore indexes.

This is particularly important because the CU3 fix specifically targets scenarios where internal engine structures—heavily used by Columnstore—can suffer from cache line contention and false sharing.

By introducing a Columnstore index, we increase:

  • parallelism

  • memory pressure

  • internal engine activity

In other words, this is where the fix should make the biggest difference.

To do this we create the following columnstore indexes on our table:

CREATE CLUSTERED COLUMNSTORE INDEX CCI_BigTable ON BigTable;


📊 STEP 6 – Benchmark Setup

In order to produce reliable and repeatable results, we installed a fresh copy of Windows 11 on VirtualBox.
We then installed SQL Server 2025 and updated it to CU2.

The virtual machine was configured with:

  • 4 CPU cores

  • 8 GB of RAM

To simulate a realistic and scalable workload, we developed a Python script that continuously creates sessions executing the following query:

SELECT SUM(c1), SUM(c2)
FROM BigTable
WHERE c1 % 10 = 0;

Every 5 seconds, a new session is added, gradually increasing concurrency until reaching 100 simultaneous sessions.

In parallel, a second Python script executes a stored procedure that periodically captures and stores key performance metrics into a SQL table.
This allows us to track CPU usage, contention, and scalability behavior over time.

Then we installed the CU3 on SQL SERVER e restarted it e running again our benchmark.

READY... FOR THE RESULTS?


📊 Benckmark results

I summarized all the results in a single chart, and I think it tells the whole story.













 
The results i got show a big difference updating to the CU3.

Load Factor 

The load Factor is where we can see the real Scalability Improvement.
  • CU2 (blue) grows much faster so CU2 accumulates more work in the queue, this is clear sign of contention
  • CU3 (orange) grows in a more controlled way, CU3 handles threads better, we have less congestion
💡 This is the first signal that the fix introduced in the CU3 reduces internal scheduler pressure


Collisions

In CU2 we have extremely high collisions (up to ~2M) while in CU3 we have much lower and more stable. This is exactly the behavior of false sharing
What it means:
multiple cores writing to the same cache line
constant cache invalidations
spinlocks going crazy

Oh yes! CU3 drastically reduces this phenomenon
👉 This chart alone proves that fix 4836787 works


SQL CPU 

Efficiency, Not Just Consumption!
In CU2 we have much higher CPU (obviuosly the values 140 means 100%)
In CU3 the CPU usage is significantly lower (~40)

👉 This is critical to understand:
It does NOT mean CU3 is slower
 It means:
➡️ CU2 wastes CPU
 ➡️ CU3 uses CPU efficiently


Wait Time 

Less Waiting means More Throughput

In CU2 we have explosive growth (over 35 million ms) 

In CU3 this is much more controlled (~23 million ms)

This mean:

  • fewer global waits

  • fewer internal bottlenecks

  • better parallelism


Max Wait Time 

Latency Under Control!
CU2 we have peaks up to ~650 ms
CU3 they remain around ~400 ms

👉 This is extremely important for real-time workloads, APIs and OLTP systems

💡 CU3 reduces the worst spikes, not just the average

Conclusion

👉 This benchmark proves that the fix:

✔ does not simply increase speed
✔ improves scalability under parallel load
✔ reduces:

  • spinlock contention

  • cache invalidation

  • CPU waste



Final Verdict: Should You Upgrade to CU3?

If you run SQL Server on:

  • multi-core machines
  • high concurrency workloads
  • analytics / columnstore queries

👉 YES. Upgrade immediately.

This is not a cosmetic fix.

We proved that this is engine-level scalability improvement.

And those are rare… and extremely valuable.



No SQL Server instances were harmed during these tests… well, at least not too much

PS: Tell me if you like this format and if you are interested in exploring other patches or topics at this level


See you in the next deep dive 👈
Luca Biondi @2026

Comments

Post a Comment

I Post più popolari

Speaking to Sql Server, sniffing the TDS protocol

Image
Hello friends!  If yesterday you read my post and found it definitely boring (for the topic of course and not for how it was written to the author 😁) well today I promise you that the topic will be much more interesting! Let's talk about Sniffing , let's talk about going to see what happens when we "log in" or when we send a Query to SQL Server.  We will do this by taking a look to the little known tabular data stream (TDS) protocol built on top of the TCP/IP protocol. Ready! The TDS protocol What is the Tabular data stream (TDS) protocol?  The TDS is the protocol used by the SQL Server client Net-Library to communicates with SQL Server . TDS is specific to SQL Server and it is a low-level protocol that specifies both commands and data in a specific arrangement.  TDS encapsulate the TCP/IP protocol. Sniffing TDS packets you can read from the network the requests that your application do to the SQL Server and read the answer .   How to Sniff data from the ne...
Read more

SQL Server, find text in a Trigger, Stored Procedures, View and Function. Two ways and what ways is better

Image
Hi guys, Welcome back! Today a light post about a question that has been asked to me several times. The question is: how to  search for text inside a trigger or a stored procedure ? We have two different ways. A first way using a system view called syscomments: SELECT obj.xtype, text , * FROM sysobjects obj JOIN syscomments com on obj.id = com.id WHERE TEXT like '%text_that_i_am_searching_for%' A second way using a system view called sql_module: SELECT o. name AS Object_Name, o. type_desc , m. definition FROM sys.sql_modules m JOIN sys.objects o ON m. object_id = o. object_id WHERE m. definition Like '%text_that_i_am_searching_for%' ;   Another question is? What differences do we have in using one way instead of the other? Which solution is better? You have to consider that the system view sys.syscomment is obsolete and will be removed sooner or later. So don't use it in production enviroiments. The sys.sql_m...
Read more

SQL Server, Avoid that damn Table Spool!

Image
Hi guys, Welcome back for another post! A light one inspired from what i do during my work: many times I optimize queries rewriting them or adding index and i like it very much! Sometimes you need to use a little imagination, but everything you learn ... sooner or later it will come in handy! Enjoy the reading mates! Avoid the Table Spool, when you can A few days ago I came across a query whose execution time was very high ... or so it was for the client complaining about the problem. Before recreating it, let's create the structures and fill the tables with some data Create table PriceList (Id int identity (1,1) primary Key ,Code Varchar (20)) Insert into PriceList (code) select top 1000 right( '0000' + cast ( row_number () over ( order by id) as varchar (4)),4) from artico Insert into PriceList (code) select top 4000 right( '1000' + cast ( row_number () over ( order by id) as varchar (4)),4) from artico Create table OrdersList (Id int identity...
Read more