During my recent SQL Server Performance Tuning Practical Workshop, someone asked, how do they know what is the automatically configured max worker threads.
Have you ever imagined how often SQL Server performance issues are actually caused by poor capacity planning? Sometimes a SQL Server database has insufficient storage performance, an instance is running out of memory, or the server level CPU is skyrocketing to an unhealthy level.
Every consulting engagement is different and I enjoy interacting with different people while I am working with different experts. Earlier this week, here is what I heard during one of the Comprehensive Database Performance Health Check engagement about Parallelism for Heap Scan.
Question: How Much Work Each Processor (CPU) is Doing in SQL Server?
Answer: To be honest, I have not seen this question asked in any of the interview questions so far. Actually, this question was asked by one of my clients during Comprehensive Database Performance Health Check. Every time whenever he logs into his system, he finds his CPU running very very high even though he had over 56 active processors. What he really wanted to know what exactly is going on behind the scene of his processors. He really wanted to figure out, how busy his servers are and how much work is pending per Processor (CPU)?
During Comprehensive Database Performance Health Check, one of the DBas asked what is the most optimal value for Max Worker Threads. The question was indeed asked when my customer looked at the value of Max Worker Threads in the Processor sections of the Server Property, they were really worried. The default value of the Max Worker Threads is always set to zero.
In this blog post, we are going to discuss how to fix high CPU Consumption on SQL Server 2016 and SQL Server 2017. One of the large multinational corporations recently hired me for Comprehensive Database Performance Health Check. Usually, customer hires me once and we are able to fix all of their problems in very little time. However, this customer had a very unique scenario and I had to engage twice to help them out.