Azure部署的ASP.NET Core 2.2应用高CPU占用问题求助

我来给你梳理几个针对性的排查方向，结合你描述的症状，这大概率是异常请求处理逻辑阻塞线程加上潜在的资源泄漏/性能瓶颈共同导致的问题：

一、优先排查耗时2分钟的CGI/502错误请求 #

这个异常请求的表现和本地差异极大，很可能是拖垮CPU的核心原因：

• 检查请求体解析逻辑：你提到接收错误请求体时未抛出预期的NullReferenceException，反而返回502。先确认代码里是不是手动读取了Request.Body（而非用模型绑定），有没有处理读取失败的情况？比如是否存在无限循环重试读取错误数据流、或者未正确关闭流导致线程阻塞的逻辑？
• 开启Azure的失败请求跟踪（Failed Request Tracing）：在App Service的“诊断工具”里启用这个功能，然后触发那个错误请求，跟踪日志会显示请求从接收到返回的全流程，包括哪个环节耗时最长、有没有未捕获的异常被Azure的请求管道吞掉。
• 核对异常处理中间件：本地能抛出NullReferenceException但Azure返回502，说明你的异常处理逻辑在Azure环境没生效。检查是否启用了UseExceptionHandler，或者有没有自定义中间件在模型绑定阶段就出现了未处理的异常，导致IIS/Azure直接返回了502而非你的自定义错误响应。

二、深入排查长期高CPU的根源 #

Kudu Profiler只抓到“某方法高负载时占40%CPU”，说明这个方法的负载依赖于请求量或数据量，需要更细粒度的分析：

• 用Application Insights的调用链与依赖映射：查看CPU飙升时段的请求链，重点看是否有外部依赖（数据库、Redis、第三方API）响应变慢，导致应用线程阻塞等待，进而引发线程池耗尽、CPU被上下文切换占满。另外检查异步方法是否都正确使用了await，避免同步阻塞线程。
• 用dotnet-trace捕获CPU轨迹：通过Kudu的SSH/PowerShell进入实例，找到你的应用进程ID（可以用dotnet list processes查看），运行命令：

  dotnet-trace collect --process-id <进程ID> --providers Microsoft-DotNETCore-SampleProfiler
  

  捕获3-5分钟的轨迹后下载到本地，用PerfView分析调用栈，就能看到那个占40%CPU的方法内部到底在执行什么（比如低效循环、频繁正则匹配、大量内存分配）。
• 检查GC与内存情况：高CPU有时是频繁GC导致的。在Application Insights查看内存指标，如果CPU飙升时内存也持续上涨，那可能存在内存泄漏（比如静态集合未清理、未释放的数据库连接/文件流）。可以用dotnet-dump工具捕获内存转储，分析对象引用链找到泄漏点。
• 排查请求流量：查看日志里CPU上涨前的请求记录，是否有大量重复请求、异常请求（比如那个返回502的请求）被高频调用？这类慢请求会占用大量线程，拖垮整体CPU。

三、关于升级S2实例后CPU仍高的说明 #

升级实例没解决问题，说明不是单纯的资源不足，而是应用本身存在性能瓶颈：

• 如果是线程池耗尽，升级实例只会增加可阻塞的线程数，CPU依然会被线程调度和等待操作占满。
• 如果是代码里存在O(n²)这类低效算法，当数据量上来后，CPU会直接跑满，升级实例无法解决算法本身的问题。

快速验证步骤 #

• 临时屏蔽那个返回502的API接口，或者在前端添加请求体校验阻止错误请求发送，观察CPU是否下降。如果下降，直接定位到该接口的错误处理逻辑。
• 在Azure上模拟正常请求，观察CPU是否会缓慢上涨。如果不会，说明问题出在异常请求的处理上；如果仍上涨，再排查正常请求的性能瓶颈。

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