起因是运维强烈认为偶发 CPU 使用率100%是一个不好的现象，我查了告诉他们原因是多线程并发垃圾回收导致 CPU 使用率高。他们硬要我解决这个问题，我只能想办法解决垃圾回收使用的 CPU 核数。

参考 .net 垃圾回收和 GCCpuGroup 配置

大致能得到如下配置，能满足运维的降低CPU使用率的需求。

<configuration>  
   <runtime>  
      <Thread_UseAllCpuGroups enabled="true"/>  
      <gcConcurrent enabled="true"/>  
      <GCCpuGroup enabled="false"/>  
      <gcServer enabled="true"/>  
   </runtime>  
</configuration>

实际操作实验时发现我对这个 CpuGroup 产生了误解，我认为主板上有2块 CPU 那就有2个 CpuGroup ，然而实际上windows默认64个 CPU 核是一个 CpuGroup。

参考 Processor Groups ，只有当 CPU 核数超过64的时候会拆分成多个 CpuGroup 。（估计是因为超多核 CPU 的线程分配和对应内存访问有关（NUMA））

难道这样就没戏了吗？哪里有64核的机器给我玩耍？微软爸爸依旧给了解决方案

Boot Parameters to Test Drivers for Multiple Processor Group Support

bcdedit.exe /set groupsize 16

这样就能在windows启动时将我现在的32核分配成2组各16核。

我就愉快的实验了一下，然而实验结果令人绝望。

MDZZ

于是现在打算每10分钟调用一个GC.Collect()，这样就不会每次回收40G内存了。