Summary
When multiple instances of MSBuild are run concurrently from the command line, each instance tries to create and claim a number of worker nodes up to the /m limit (which is NUMPROCS for dotnet by default).
This can lead to entirely too many nodes existing on the host machine, lingering for the configured timeout, which is ~15m by default.
These nodes suck up machine resources and look bad - the engine should work to minimize the number of active nodes past an expected threshold to preserve system resources.
Background and Motivation
As more tools, like DevKit, LLM Agents, and human users, delegate their build and inner-loop experiences to the dotnet CLI, it becomes more and more likely that collisions like the above will occur. I was looking at node trace logs this morning where more than 25 worker nodes were lingering on the machine. Managing these nodes is a pain for users of all kinds - you either have to carefully sequence your build operations, apply /nodereuse:false which slows down subsequent builds, or dangerously and likely incompletely terminate processes.
Proposed Feature
Instead, the nodes themselves should clean themselves up.
When a build completes and an out of proc node marks itself idle, it should attempt to handshake with its siblings. If there are a number of active nodes of the same type equal to a threshold, the idling node should terminate.
Proposed thresholds:
- Worker nodes: NUM_PROCS/2
- Server Nodes: > 0
- RAR-as-a-service-node: 1 ever, AND that node should be able to work with any number of concurent builds - meaning that the node doesn't get 'locked' to a build
Alternative Designs
No response
Summary
When multiple instances of MSBuild are run concurrently from the command line, each instance tries to create and claim a number of worker nodes up to the
/mlimit (which is NUMPROCS fordotnetby default).This can lead to entirely too many nodes existing on the host machine, lingering for the configured timeout, which is ~15m by default.
These nodes suck up machine resources and look bad - the engine should work to minimize the number of active nodes past an expected threshold to preserve system resources.
Background and Motivation
As more tools, like DevKit, LLM Agents, and human users, delegate their build and inner-loop experiences to the
dotnetCLI, it becomes more and more likely that collisions like the above will occur. I was looking at node trace logs this morning where more than 25 worker nodes were lingering on the machine. Managing these nodes is a pain for users of all kinds - you either have to carefully sequence your build operations, apply/nodereuse:falsewhich slows down subsequent builds, or dangerously and likely incompletely terminate processes.Proposed Feature
Instead, the nodes themselves should clean themselves up.
When a build completes and an out of proc node marks itself idle, it should attempt to handshake with its siblings. If there are a number of active nodes of the same type equal to a threshold, the idling node should terminate.
Proposed thresholds:
Alternative Designs
No response