Azure App Service间歇性挂起问题：是否为线程池耗尽所致？

我们创建了一个逻辑应用，每30秒ping一次基础诊断端点并记录结果。发现该端点通常耗时300-400ms，但会突然出现峰值，最长需50秒才返回！

分析日志时发现，ThreadPool.PendingWorkItemCount数值约为100，而正常运行时该值始终为0。

因此我们疑似遭遇了某种形式的线程池耗尽问题。

是否有办法追踪这些线程的来源？例如，若存在后台进程或定期更新的过期缓存，该如何追踪？

ThreadPool对象仅提供极少的公共方法/属性供我们详细排查。

诊断示例：

{
  "start": "2023-05-04T12:17:03.0518943Z",
  "end": "2023-05-04T12:17:06.6382781Z",
  "threadCount": 8,
  "pendingWorkItemCount": 32,
  "workerThreads": 32762,
  "completionPortThreads": 1000,
  "maxWorkerThreads": 32767,
  "maxCompletionPortThreads": 1000
}

我们的某个Azure App Service出现异常问题：每日不定时会突然挂起30-50秒，期间无法处理任何请求，如同冷启动一般。

该应用是基于.NET 7的ASP.NET MVC（C#）单体应用，包含DI服务层（非API架构，全部封装于同一应用内），大量使用Azure Redis作为缓存，后端为Azure SQL，同时广泛使用Azure Storage（表、Blob和队列）。

应用全程采用async-await模式，几乎无同步调用或明显阻塞线程的操作，未发现长时间锁定资源的情况。

应用无需调用第三方API，极少使用外部CDN，所有依赖均在上述架构范围内。

MVC应用部署于P2V2实例（210 vCPU、7GB内存），已横向扩展至2个实例（启用会话亲和性）；Redis实例为P1 Premium（6GB缓存）；Azure SQL为Standard S4（200 DTUs），在英国南部（读写）和英国西部（只读）之间进行异地复制，应用通过两个连接字符串实现读写分离以负载均衡SQL服务器。

正常运行时应用响应极快（毫秒级），但每日会无规律出现数次（约5次）双实例同时挂起的情况，持续最长50秒，期间浏览器加载无响应，之后突然恢复正常性能，并非冷启动（此前运行正常）。

挂起期间我们排查了多类诊断数据源，未发现异常：

• 两台实例的App Service CPU使用率均未超过15%
• 内存使用率无突增
• 读写和只读SQL服务器的DTU%通常为5-15%
• Redis内存使用率无突增，仅约200MB
• Redis服务器负载通常为5-6%
• Azure Storage的入站/出站流量无峰值
• Application Insights未发现异常
• 无错误、警告等突增情况
• 诊断事件日志无异常
• 未发现超时或其他延迟问题
• 无后台、定时或CRON任务运行
• 数据库查询已优化且索引完善
• 健康检查始终为100%
• Azure日志显示实例未重启，正常运行时间保持100%

当前所有架构资源均远超需求规格，未发现防火墙等其他明显影响因素。

该问题疑似源于MVC、.NET或App Service平台内部，无法在本地开发环境复现，也无法预测生产环境的发生时间。

我们曾考虑GC回收或数据库连接池回收等可能性，但未找到相关数据支持。

是否可能是Application Insights导致的问题？它是否会定期转储或刷新数据/缓存？感觉问题来自平台、托管环境或框架层面。

我们目前陷入困境，除每日这些短暂峰值外，应用运行良好且响应迅速，这一状况令人困扰。

我们已向Azure Support提交工单等待反馈，请问是否有其他用户遇到过类似架构下的相同问题？能否提供排查方向或可添加的日志/诊断手段以追踪问题根源？

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