为何CreateNoWindow会影响Azure HBv2 VM的CPU核心利用率？

在Azure Batch的HBv2虚拟机上，我尝试实现100%的CPU利用率，编写了基于.NET Framework 4.7.2的C#测试程序：

• 获取处理器数量后，创建对应数量的子进程，每个子进程生成质数30秒
• 已在app.config中添加以下配置：

<runtime>
    <Thread_UseAllCpuGroups enabled="true"/>
    <GCCpuGroup enabled="true"/>
    <gcServer enabled="true"/>
</runtime>

此时Environment.ProcessorCount返回120，但使用以下代码创建子进程时：

new ProcessStartInfo
{
    FileName = processFileName,
    Arguments = i.ToString(),
    CreateNoWindow = true,
    UseShellExecute = false
};

CPU利用率仅约70%，任务管理器显示两个NUMA节点利用率达100%，另外两个约为50%。若将CreateNoWindow设为false，则能达到100%的CPU利用率。请问为何CreateNoWindow标志会造成这种差异？

这个现象的核心和Windows的**进程亲缘性（Processor Affinity）**以及无窗口进程的初始化逻辑直接相关：

1. 无窗口进程的默认亲缘性限制
   当设置CreateNoWindow = true且UseShellExecute = false时，子进程以无控制台窗口的方式启动。在多NUMA节点的系统（比如HBv2的4个NUMA节点）中，这类进程初始化阶段会被默认绑定到父进程所在NUMA节点的CPU核心，无法自动调度到所有可用核心。而CreateNoWindow = false时，子进程会创建控制台窗口，Windows会为控制台进程分配更宽松的亲缘性策略，允许进程调度到所有NUMA节点的核心。

2. .NET配置的作用范围局限
   你在父进程app.config中配置的Thread_UseAllCpuGroups等参数仅作用于父进程本身，不会自动传递给子进程。子进程需要在自身的配置文件中添加相同的运行时配置，才能正确识别并使用所有CPU组和NUMA节点。

3. NUMA节点负载的验证逻辑
   两个NUMA节点满负载、另外两个半负载的现象，正好对应子进程被限制在部分NUMA节点的情况——父进程可能运行在前两个NUMA节点，无窗口子进程继承了这个亲缘性限制，无法调度到后两个节点的核心，最终导致整体CPU利用率仅约70%（120核心中约80个被充分利用）。

• 给子进程的可执行文件添加对应app.config，确保子进程也启用Thread_UseAllCpuGroups、GCCpuGroup和gcServer配置，让子进程能识别所有CPU组。
• 手动设置子进程的处理器亲缘性：启动子进程后，通过Process.ProcessorAffinity属性指定子进程可使用所有CPU核心（比如设置为(IntPtr)(-1)表示所有核心），强制打破默认的亲缘性限制。
• 若业务允许，保持CreateNoWindow = false的方式启动进程，利用Windows控制台进程的默认调度策略。

内容的提问来源于stack exchange，提问作者Mal Pirie