Server 2008 R2 Thread Scheduling

[winelement]

Hello,

I have a question regarding multiple single threaded processes running on a dual core (single phyiscal core) server. We have have a Windows Server 2008 R2 running as a file and print server in this environment. Since each process is only single threaded, is it useless to have dual cores as usual logic would dictate? Upon checking the resource monitor, Windows seems to balance single threads over both cores.

I've researched and discussed this for a few days and have learned quite a bit but do not have a definitive or authoritative answer. I've learned in our case a file and print server can use dual cores since the Windows Scheduler will balance the threads over the multiple CPU's depending on how busy a processor is at any given time. File and print services are not multithreaded so does the OS scheduler simply handle this at a native function? I do not know if the single process for print services (spoolsv) can create multiple threads as I assumed it would when necessary.

Also, does this change in a virtual environment say VMwares VSphere 4 which is a Linux Kernel passing to Win OS? VMware recommends a single processor for every VM in this single threaded scenario or there can be performance loss. So assuming appropriate CPU utilization, I'd have to split the file and print server into two separate VM's as recommended by VMware which adds an additional license than simply keeping a single VM with 2 vCPU's.

Thank you.

[cluberti]

It sounds like you might want to pick up Windows Internals (5th Edition) from Mark Russinovich and start reading on page 391, but to answer your questions:

On a multiprocessor system, the Windows thread scheduler can schedule any thread on any available processor, and it keeps a "database" (actually called the dispatcher database) of which threads are waiting to run, which processors are executing which threads currently, and each processor in a system has it's own dispatcher ready queue (it speeds up and makes more efficient the thread manager's dispatch decisions). Each thread can be in any one of a number of actual states - specifically:

• Ready: A thread is waiting to execute, and is in the pool of threads that the scheduler can choose to schedule to a processor.
• Deferred Ready: A thread has been selected to run on a processor, but isn't actually scheduled to run yet.
• Standby: A thread that has been assigned a processor to run, and is on the list waiting to be chosen to run (only one thread per processor can be in this state). Unless pre-empted by a higher-priority thread, this is going to be the next thread that the processor is context-switched to when the current thread is finished or is switched off after it's quantum time has completed.
• Running: I think this one is obvious .
• Waiting: A thread is waiting on something to finish before it can continue (that something can be waiting for an object synchronization, waiting for an I/O completion, or any number of other events that the thread is waiting to fire before it will continue).
• Gate Wait: A thread specifically waiting on the gate dispatcher object - this is a heavily optimized call that disables all kernel-mode APC, avoids raising to IRQL to APC level, and doesn't need a global dispatch lock, and is a very special kind of wait.
• Transition: A thread is ready to execute, but it's stack is currently paged out of memory - once the memory is faulted back into memory, this thread will execute.
• Terminated: A thread in this state isn't actually "gone", but it is in a state that allows the object manager policy to determine whether or not to de-allocate this thread's executive thread block.
• Initialized: A thread is being created when in this state

As to your question about the Print Spooler, spoolsv.exe is indeed multithreaded, and can create threads across multiple processors. File services are handled by the server service, which runs inside of an svchost.exe process, which is also multithreaded. Again, the thread can run on any CPU, and the thread scheduler takes care of it based on load, queues, priority, etc.

As far as a virtual environment, if VMWare is saying that you should create single-CPU VMs to run Windows, then you should probably do that. Windows running in the VM won't have any idea about the "hardware" underneath, and it will behave as if the VM is a real system and thread schedule accordingly. If VMWare is saying to run a Windows VM as a single-CPU VM, it may be due to the way their VM kernel handles the thread scheduling, etc, and it may be suboptimal code underneath so they're trying to avoid problems in the VM. I don't know this for sure, but I would recommend going with whatever the vendor recommends in those scenarios. You might want to ask VMWare specifically how many virtual CPUs are supported being assigned to each version of Windows Server that would run in the environment (Server 2003, Server 2008, Server 2008 R2, etc) and go with that recommendation. Again, the Windows installation in the VM won't know any different, so it will thread schedule in a VM with multiple virtual CPUs the same way it would in a physical machine with multiple CPUs, so if the vendor has specific rules for their VM environment, it's best to follow those.

[winelement]

Cluberti,

Thank you for your resourceful reply, I appreciate it.

Cheers!

[winelement]

Just a follow up here since I've received an official VMware answer to this. VMware Vsphere 4 does not alter native Windows Server Scheduling.

Edited March 11, 2010 by winelement

[cluberti]

Correct - to do so they'd have to replace the kernel with their own custom version (it is possible and Compaq used to do it with a lot of their older PCs, but I've not ever seen VMWare do this in the past).

[nmX.Memnoch]

it is possible and Compaq used to do it with a lot of their older PCs

*shivers at the thought*

Yeah...those days sucked. You couldn't just install a Service Pack when it was released, you had to wait for Compaq to release their SoftPaq version. Bleh...