NCrunch uses two process pools - one for build processes, and one for test processes.

The max effective build process pool size is always set to the max number of processing threads setting.

The max effective test process pool size is equal to the process pool size setting, plus the max number of processing threads.

This means that in your situation, the max number of task runners you can see when the engine is idle will be: 2 [max processing threads for build pool] + 2 [max processing threads for test pool] + 1 [process pool size] = 5.

The grid node also keeps a separate process pool for each active connection. So if you opened two instances of Visual Studio pointing at the same node, you'll see up to 10 task runners operating on the node at any one time.

I admit that this isn't probably the behaviour many people would expect when looking at these configuration settings. The formula for calculating process pool size has changed several times throughout NCrunch's lifespan. The current approach seems to work well for reducing unnecessary process recycling, while still giving some level of control over memory consumption.

In theory, it should be possible to set the process pool size to a negative value, thus offsetting the effect of max processing threads. However, I would recommend against this as your performance will probably fall through the floor. If memory consumption is a concern, there are more effective ways of reducing this through the other configuration settings.