You can think of the SQL Server scheduler as a logical CPU
used by SQL Server workers. A worker can be either a thread or a fiber that is
bound to a logical scheduler.
If the Affinity Mask Configuration option is set, each scheduler is affi nitized to a particular CPU. Thus, each worker is also associated with a single CPU. Each scheduler is assigned a worker limit based on the configured Max Worker Threads and the number of schedulers, and each scheduler is responsible for creating or destroying workers as needed. A worker cannot move from one scheduler to another, but as workers are destroyed and created, it can appear as if workers are moving between schedulers.
Workers are created when the scheduler receives a request (a
task to execute) and there are no idle workers. A worker can be destroyed if it
has been idle for at least 15 minutes, or if SQL Server is under memory
pressure. Each worker can use at least half a megabyte of memory on a 32-bit
system and at least 2 MB on a 64-bit system, so destroying multiple workers and
freeing their memory can yield an immediate performance improvement on memory-starved systems. SQL Server actually
handles the worker pool very effi ciently, and you might be surprised to know
that even on very large systems with hundreds or even thousands of users, the actual number of SQL
Server workers might be much lower than the confi gured value for Max Worker
Threads.
