ASP.NET Core 6 Web App在AKS环境中CPU飙升后异常激增是否正常？

这种行为完全不正常，高CPU使用率与后续的异常抛出几乎必然存在直接关联，结合你观察到的“CPU飙升在前、异常在后”的时序，常见关联场景如下：

核心关联逻辑 #

• 线程饥饿/请求超时：CPU被占满时，应用的请求处理线程长时间被占用，新请求排队等待超时，会触发TimeoutException、TaskCanceledException这类异常；如果线程池无法及时扩容（默认线程池扩容有延迟），还会导致请求无法被调度，抛出操作取消类异常。
• 资源竞争与耗尽：高CPU通常伴随高并发，若代码中存在未正确同步的共享资源访问，会引发InvalidOperationException、NullReferenceException；同时数据库连接池、Redis连接池等资源可能被耗尽，导致数据库操作超时或连接失败异常。
• GC压力连锁反应：高CPU可能是频繁Full GC导致的（比如内存泄漏、大对象分配过多），GC的Stop-The-World（STW）暂停会中断请求处理，引发超时或中断类异常；长期GC压力也会拖垮服务处理能力，间接导致异常。
• 服务熔断触发：如果应用配置了熔断组件（如Polly），当CPU飙升导致服务响应恶化到阈值，熔断机制会直接拦截后续请求，抛出熔断相关异常，避免服务彻底崩溃。

排查建议 #

• 抓取CPU飙升时段的进程转储：在AKS Pod内执行dotnet-dump collect -p <进程ID>，用dotnet-dump analyze分析线程栈，定位占用CPU的热点代码。
• 聚焦异常细节：查看应用日志中异常的具体类型和调用堆栈，比如是超时类、资源竞争类还是GC相关异常，针对性排查对应代码逻辑。
• 检查AKS资源配置：确认Pod的CPU请求（request）和限制（limit）是否匹配应用实际负载，若CPU被Kubernetes限流（Throttling），会直接限制应用处理能力，引发后续异常。
• 监控GC指标：查看.NET Runtime指标中的GC暂停时间、堆内存增长速率、GC回收次数，判断是否是GC导致的CPU飙升和异常。

内容的提问来源于stack exchange，提问作者Florin-Constantin Ciubotariu