ASP.NET Parallel.ForEach未占用全部CPU核心故障排查咨询

你遇到的是KB5013871补丁引入的.NET Framework 4.6.2线程调度回归问题，该问题在IIS托管ASP.NET场景下会触发Parallel.ForEach无法正常向线程池申请工作线程，最终所有任务串行在单核心执行，和你描述的现象完全匹配。按以下优先级排查修复： #

1. 补丁问题验证与修复 #

• 优先临时卸载KB5013871补丁，重启服务器后重跑任务，若CPU占用恢复至90%区间即可确认根因。
• 不建议长期停留在旧补丁版本，直接安装2022年6月及之后发布的.NET Framework 4.6.2安全与质量汇总补丁即可修复该调度bug，不需要额外改代码或配置。

2. 运行时与IIS配置排查 #

如果更新/卸载补丁后问题仍存在，逐项检查以下配置：

• 检查应用程序池线程池配置：打开C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet.config，确认<processModel>节点下的MaxWorkerThreads没有被手动修改为过低值，默认配置为每核心100个工作线程，数值过低会直接限制并行度。
• 修复多CPU组识别异常：双路物理服务器在安装2022年早期.NET补丁后可能出现CPU组识别错误，在站点web.config的<runtime>节点添加以下配置，强制运行时调度覆盖所有核心：

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

注意：必须同时开启gcServer，前两项CPU组配置才会生效。

• 校验IIS CPU节流配置：你当前设置的CPU限制值900对应90%上限是正确的，但需要确认CPU节流操作选项未设置为Throttle/ThrottleUnderLoad——补丁修改了CPU占用统计逻辑后，这两个模式会误判当前CPU占用已达阈值，主动锁死线程调度。临时将CPU限制调整为1000（即关闭CPU节流）测试是否恢复。
• 检查进程亲和性：在任务管理器找到对应w3wp工作进程，右键打开「设置相关性」，确认所有32个核心都处于勾选状态，没有被误配置为单核绑定。
• 检查电源计划：确认服务器运行在「高性能」电源模式，排除节能模式主动休眠核心、限制频率导致的并行度不足。

3. 代码层面临时规避方案 #

如果暂时无法调整服务器补丁或配置，可以通过代码修改绕过调度bug：

• 不要使用默认的Parallel.ForEach重载，手动指定分区器消除任务调度开销，同时固定并行度数值，避免动态获取核心数出现异常：

// 关闭分区缓冲，避免任务被串行批量投递
var customPartitioner = Partitioner.Create(你的数据源集合, EnumerablePartitionerOptions.NoBuffering);
Parallel.ForEach(customPartitioner, new ParallelOptions
{
    MaxDegreeOfParallelism = 31 // 固定为总核心数-1，不动态读取Environment.ProcessorCount
}, item => {
    // 原有运算逻辑
});

• 如果以上修改仍不生效，直接手动创建31个长生命周期Task，从预加载的内存集合中拉取数据执行，完全绕过Parallel默认的线程池调度逻辑即可。

4. 其他干扰项排查 #

• 临时卸载/禁用服务器上安装的端点防护、安全加固类软件，这类软件更新后可能注入w3wp进程Hook线程创建API，直接阻止并行线程创建。
• 不要通过调整IIS最大工作进程数解决问题，多工作进程会导致你预加载到内存的数据集多份复制，反而会增加内存开销、触发GC锁导致性能下降。

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