生成多个Sub-Orchestrator时内存不足异常（工作项队列限制？）

问题核心分析 #

从异常栈可以明确，OutOfMemoryException发生在System.Convert.ToBase64String环节，本质原因是子编排器一次性创建大量Activity任务时，需将所有任务的调度信息序列化并加载到内存中，当任务量达到万级规模时，序列化后的历史数据占用内存超出函数实例的内存上限，直接触发崩溃。

关于工作项队列的限制说明 #

Azure存储队列本身没有严格的容量限制（单个队列最大可存储500TB数据，单条消息最大64KB），也无硬性速率限制（仅受存储账户吞吐量约束，标准存储账户最高支持2000条消息/秒）。你遇到的3万条阈值并非队列本身的限制，而是Durable Functions编排器的内存瓶颈——编排器采用单线程执行模型，需在内存中维护所有待调度任务的状态与历史记录，当任务量过大时，内存占用直接触顶。

有效解决方案 #

1. 拆分子编排器的任务粒度 #

不要让单个子编排器一次性创建1万条Activity任务，将任务拆分为更小的批次：

• 原逻辑：单个子编排器直接创建10000个Activity
• 优化后：单个子编排器先创建100个“批次任务”，每个批次任务再创建100个Activity处理记录
  通过缩小单次调度的任务范围，大幅降低子编排器的内存占用。

2. 限制Activity并发数 #

在host.json中配置Durable Task的并发限制，避免瞬间创建过多任务导致内存压力：

{
  "extensions": {
    "durableTask": {
      "maxConcurrentActivityFunctions": 200,
      "maxConcurrentOrchestratorFunctions": 50
    }
  }
}

可根据函数实例的内存规格调整数值，平衡并行效率与内存占用。

3. 分批创建Activity任务 #

修改子编排器逻辑，避免一次性生成所有Activity调用，改为分批调度：

// 原逻辑：一次性创建所有任务
var allTasks = records.Select(record => context.CallActivityAsync("ProcessRecord", record)).ToList();
await Task.WhenAll(allTasks);

// 优化后：分批创建任务
int batchSize = 200;
for (int i = 0; i < records.Count; i += batchSize)
{
    var batch = records.Skip(i).Take(batchSize);
    var batchTasks = batch.Select(record => context.CallActivityAsync("ProcessRecord", record)).ToList();
    await Task.WhenAll(batchTasks);
}

分批执行可让编排器逐步释放已完成任务的内存，避免内存持续累积。

4. 升级函数实例规格 #

若使用消耗计划，可切换至高级计划或专用计划，选择内存更大的实例（如D3v2、D4v2），为编排器提供更多内存空间处理大规模任务。

重试策略无效的原因 #

你配置的重试策略针对的是CallSubOrchestratorAsync的调用失败，但OutOfMemoryException是在子编排器执行过程中抛出的，并非子编排器调用阶段的失败，因此重试策略不会触发。且内存溢出是任务量过大导致的本质问题，重试只会重复触发相同崩溃，无法解决根源。

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