使用PerfView追踪后ASP.NET MVC服务出现GC导致的持续高CPU问题

残留ETW会话的可能性确认 #

该异常确实存在服务器重启后仍有追踪会话残留引发问题的可能，核心原因是.NET 4.7.2版本的已知ETW追踪泄漏缺陷：

• 开启ETW .NET Alloc采集选项时，CLR会注册全局的托管对象分配回调钩子，若PerfView会话因权限不足、进程意外终止等原因未执行正常的停止清理流程，该钩子不会被自动注销
• 即便执行iisreset、服务器重启操作，若系统中存在残留的自动启动ETW会话配置，或是CLR在进程启动时检测到遗留的追踪标志位，仍会自动加载分配回调逻辑：每一次托管对象分配都会触发额外计算开销，同时生成大量临时追踪对象，进一步放大GC压力，最终表现为GC占用全核CPU
• 排查方式：执行命令 logman query -ets 查看当前系统中运行的所有ETW会话，若存在PerfView相关的残留会话，执行 logman stop <会话名称> -ets 即可清理

其他可能的触发原因 #

如果清理ETW残留后问题仍复现，可从以下方向排查：

• 业务流量/逻辑差异：确认该服务器是否承接了集群其他节点没有的特殊流量（如灰度请求、爬虫流量、异常参数批量请求），触发了未覆盖的大对象分配逻辑，导致LOH碎片化加剧，GC不得不频繁执行全堆扫描回收空间
• GC配置差异：对比该服务器与正常节点的machine.config、站点web.config配置，确认GC模式是否一致：多核心服务器场景下若误配置为工作站GC、关闭后台GC，会直接引发GC时全核占满的阻塞问题
• 部署变更差异：确认该服务器是否存在未同步到其他节点的隐式变更，如配置文件调整、依赖包热更新、IIS应用池配置修改，这类变更会直接改变站点的内存分配特征

快速恢复方案 #

若需要快速恢复业务，可先将该服务器从集群下线，安装.NET 4.8运行时（修复了多个ETW追踪泄漏和GC性能缺陷），重新部署站点后再上线验证。

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