The importance of the worker threads is always on
Most of my blog posts are an outcome of the work that I do over the weekend while holding the pager for my team. This blog post is no different. In this blog post, I will talk about the importance of the worker threads in Always On availability group. We will also learn what worker threads are so we can understand things better. And, when we understand how it works, it will be much easier to follow things in detail.
What is worker thread?
Sometimes it is confusing to relate threads in SQL Server to the ones with the OS threads. But they are different. For SQL Server, the threads (worker threads) sit on top of the OS threads. Whenever a request comes in, the User Mode Scheduler (UMS) manages the execution of the request. These are the worker threads that are used here. There will be a single UMS for each CPU. At any point, UMS will have a running queue of requests waiting for CPU, IO Locks, Memory and or user requests. The worker thread is a configurable option but at the same time, you should be cautious as an inaccurate or improper configuration of this option can cause performance issues. For a better understanding of what the best possible value for the worker thread can be, I suggest reading the updated document on the Microsoft site here. Now that we know what a worker thread is, let's jump into the main topic - the importance of the worker threads in Always On. Always On Availability Groups is an enhanced version of DB Mirroring. Always On Availability groups carry out tasks such as:- Log capture
- Log send queue/Redo queue
- Message handler
