Azure Function高级计划出现线程池饥饿等警告：原因与解决

我有一个基于.NET Core 8的Azure Function（采用Premium计划），近期在日志中发现以下警告及信息：Host CPU阈值超标、检测到可能的线程池饥饿、启用Drain Mode、监听器停止。但代码最终执行成功（提示LeadsData已成功处理），未抛出异常。现咨询：

1. 这些现象的原因是什么？
2. 如何预防此类警告？
3. 这些警告是否会导致代码后续抛出异常？

附引发该问题的核心代码（读取SharePoint中含35K行的Excel并构建列表）：

string siteUrl = "https://*****.sharepoint.com/sites/marketing";
string tenant = "*****";
string site = "marketing";
string listTitle = "Documents";
siteUrl = $"https://{tenant}.sharepoint.com/sites/{site}";
string apiBaseUrl = $"{siteUrl}/_api/web/lists/GetByTitle('{listTitle}')/items";
var httpClient = new HttpClient();
httpClient.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", accessToken);

// Build SharePoint API URL

var relativeFilePath = "/sites/marketing/Shared Documents/Reporting/BGG - ROI by tactic.xlsx"; // relative to tenant
string uri = siteUrl + "/_api/web/getfilebyserverrelativeurl('" + relativeFilePath + "')/$value";
var stream = await httpClient.GetStreamAsync(uri);
// 3. Open Excel as stream with OpenXmlReader
using var workbook = new XLWorkbook(stream);
var worksheet = workbook.Worksheet(1); // First worksheet
List<string> duplicateMSID = new List<string>();//to store the MSID incase it was already read, only latest MSID
List<BGGROIByTactic> duplicateBGGROI = new List<BGGROIByTactic>();
var headerRow = worksheet.Row(1);
var columnMap = new Dictionary<string, int>();

for (int i = 1; i <= headerRow.LastCellUsed().Address.ColumnNumber; i++)
{
  string header = headerRow.Cell(i).GetString().Trim();
    if (!string.IsNullOrWhiteSpace(header))
        columnMap[header] = i;
}
int lastRow = worksheet.LastRowUsed().RowNumber();
for (int i = lastRow; i >= 2; i--)
{
    var row = worksheet.Row(i);
    if (row.IsEmpty()) continue;
    
    var firstCellValue = row.Cell(columnMap["SID"]).GetString();
    
    string vnumber = row.Cell(columnMap["MSID"]).GetString();
    
    if (vnumber != null && leads.Where(a => a.MSID == vnumber).Count() > 0 && duplicateMSID.Where(x => x == vnumber).Count() == 0)
    {
        //build the list to duplicate the excel

        var updates = leads.Where(a => a.MSID == vnumber);
        foreach (var update in updates)
        {

            update.UMSID = row.Cell(columnMap["UMSID"]).GetString();

            update.Publisher = row.Cell(columnMap["Publisher"]).GetString();

            //values go here...

        }

    }
}

1. 现象原因 #

• Host CPU阈值超标：35K行Excel的处理逻辑存在大量低效同步计算，比如循环中反复调用leads.Where(...).Count()，每次都会遍历整个leads集合；加上XLWorkbook一次性加载全量Excel数据到内存，导致CPU持续高负载，触发Azure Function的CPU阈值告警。
• 线程池饥饿：代码仅在读取Excel流时用了异步操作，后续的Excel解析、循环遍历都是同步阻塞逻辑，持续占用线程池工作线程，线程池无法及时补充线程处理其他内部任务，进而触发线程池饥饿检测。
• 启用Drain Mode、监听器停止：Azure Function宿主检测到CPU过载或线程池异常时，会启动Drain Mode——停止监听器接收新请求，优先保障已有请求执行完成，避免资源彻底耗尽。你的代码能执行成功，正是因为Drain Mode允许当前请求跑完。

2. 预防措施 #

• 优化集合查询性能：将leads转换为以MSID为键的字典，避免循环中反复遍历全量集合：

  var leadsByMSID = leads.GroupBy(a => a.MSID).ToDictionary(g => g.Key, g => g.ToList());
  

  后续判断MSID是否存在、获取对应数据，直接用字典的ContainsKey和索引访问，替代低效的Where(...).Count()，大幅降低CPU消耗。
• 异步化CPU密集操作：将Excel处理的循环逻辑放到Task.Run中，释放线程池工作线程（仅适用于CPU密集场景）：

  await Task.Run(() => {
      // 原Excel循环处理代码
  });
  

• 复用HttpClient：不要每次函数执行都新建HttpClient，通过依赖注入注入单例HttpClient，避免socket资源泄漏和性能损耗。
• 分批处理数据：把35K行Excel拆分成多批处理，每批处理后短暂释放资源，避免长时间占用CPU和线程。
• 调整实例资源：如果业务量持续较大，升级Premium计划的实例大小或增加实例数量，提升宿主的CPU和线程资源上限。
• 优化Excel读取：改用OpenXmlReader流式读取Excel，避免一次性加载全量数据到内存，减少内存占用和CPU负载。

3. 是否会导致后续异常 #

• 短期来看，当前请求能完成，但如果频繁触发这些警告，后续必然出现问题：
  • Drain Mode频繁触发会导致新请求被拒绝，业务中断；
  • 线程池饥饿持续存在，会引发函数内部异步操作超时、死锁；
  • 长期高CPU负载会触发Azure强制重启实例，正在处理的请求可能中途失败；
  • 资源耗尽严重时，后续请求会直接抛出OutOfMemoryException、TaskCanceledException等资源不足异常。
• 若不优化，随着Excel行数等数据量增长，这些警告会越来越频繁，最终必然导致执行失败。

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