Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I'm currently trying ot figure out a decent/nice way of determening what core(s) a single service should run on, in Windows Server 2008.

I'm aware that for procceses there is two ways to do it:

  1. set affinity through task manager after proccess is launched.
  2. use "start /AFFINITY 0x1" or similar bitmask

However this does not seem to work very well with services. When i try to launch the exe that the service will also run (the one that needs restriction) it just spawns a new commandline. (cmd.exe)

Does anyone here know how to do a similar trick for services? It is not important what core it is running on, it just needs to be restricted to only one. And preferably it should be something that can be automated, so we do not have to interfere when there is a server restart.

share|improve this question
    
Are you absolutely sure you need to do this? It will have a negative impact on performance, particularly of any tasks running on the other cores. (Because they'll compete with the service for memory bandwidth and kernel locks more frequently. The fewer cores the service runs on, for a given load, the higher the percentage of the time it will be running, thus the more likely it will compete with other programs for memory bandwidth, kernel locks, and so on, slowing them down.) –  David Schwartz Nov 26 '12 at 12:26
    
Even worse, say some other application is running on that core because the service is idle. Then the service has work to do with a higher dynamic priority. Since it can only run on that core, the other application must be migrated to another core. But now, all the caches are blown out. Scheduler flexibility is extremely valuable. Take it away only if you have no other choice. –  David Schwartz Nov 26 '12 at 12:34
    
I'm aware of the negative performance impact. But the service in question is part of a monitoring program, and the switching between cores causes something to go wrong with the monitoring software, so the results it delivers become unpredictable and sometimes directly wrong. We have investigated it and found out that limiting the program to one core eliminates this issue. It's not optimal, but thats what we got I'm afraid. –  Martinnj Nov 26 '12 at 12:35
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.