Docker中并行任务运行缓慢：弱本地为何比强EC2快4倍？

1. Docker容器资源限制未适配EC2硬件 #

默认情况下Docker可能不会自动分配全部宿主机CPU资源，如果你的容器被限制了CPU核心数（比如仅分配4核，和本地一致），32核的EC2优势完全无法发挥。同时，10个job × 12个子任务的高并发量，在有限核心下会引发频繁线程上下文切换，反而降低整体效率。

• 排查方法：执行docker stats查看容器的CPU使用率和配额限制；检查容器启动命令是否包含--cpus、--cpu-shares等限制参数。
• 解决：根据EC2配置设置合理的CPU配额，例如docker run --cpus 30 ...（预留少量核心给系统进程）。

2. .NET线程池配置未优化 #

.NET线程池的最小工作线程数默认会根据CPU核心数调整，但在Docker容器中，早期.NET版本可能无法正确识别宿主机核心数，导致线程池扩容不及时。你的任务以IO密集型操作为主（HTTP、SQL、S3操作），需要足够线程处理异步等待，若线程池线程不足，大量任务会排队等待分配。

• 排查方法：在代码中添加日志输出ThreadPool.GetMinThreads(out int worker, out int io);，查看初始线程池配置；在任务执行前后记录线程池活跃线程数。
• 解决：应用启动时手动设置线程池最小线程数，示例：

  ThreadPool.SetMinThreads(64, 64); // 根据EC2核心数调整，建议设为核心数的2-4倍
  

3. 数据库/HTTP/S3连接池瓶颈 #

你的任务包含大量SQL、HTTP和S3操作，默认连接池大小可能无法支撑120个并发任务。本地并行度低（4核下实际并发线程数远少于120），连接池足够用；但EC2高并发下，任务会等待获取连接，导致整体耗时剧增。

• 排查方法：查看数据库（如SQL Server的sys.dm_exec_connections）、HTTP客户端（如HttpClient连接池配置）、AWS SDK的S3连接池的活跃连接数和等待队列。
• 解决：调整各类连接池最大连接数：
  • SQL Server连接字符串添加Max Pool Size=100（按需调整）；
  • 用HttpClientFactory管理HttpClient并配置合理连接数；
  • 调整AWS SDK的AmazonS3Config.MaxConnections参数。

4. Nginx反向代理性能瓶颈 #

如果应用通过Nginx转发请求，默认配置可能无法支撑高并发。比如worker_processes未匹配CPU核心数、worker_connections过小，或请求缓冲、超时配置不合理，都会导致请求排队或延迟。

• 排查方法：查看Nginx日志中的upstream_response_time和request_time统计延迟；执行nginx -V查看编译参数，检查worker_processes配置。
• 解决：优化Nginx配置，示例：

  worker_processes auto; # 自动匹配CPU核心数
  worker_connections 10240; # 提高最大连接数
  keepalive_timeout 60;
  

5. 代码中的潜在问题 #

你的示例代码存在变量名重复错误，会导致子任务未正确添加到列表，实际并行度远低于预期，不同环境下表现可能不一致：

// 错误代码
for (var m = 1; m < 13; m++){
     var subTasks = Task.Factory.StartNew(() =>{ // 变量名与外层List<Task>重复
          // process task
     });
     subTasks.Add(subTasks); // 实际添加的是新声明的Task，而非外层列表
}

• 解决：修正变量名并避免闭包捕获循环变量问题：

  for (var m = 1; m < 13; m++){
     var month = m; // 捕获当前循环的月份值
     var task = Task.Factory.StartNew(() =>{
          // 使用month处理对应月份任务
     });
     subTasks.Add(task);
  }
  

关于应用预热的可能性 #

应用预热（如JIT编译、连接池初始化）通常只影响首次运行耗时，但你测试单任务时EC2性能更优，说明预热已完成。因此并行任务的耗时差异大概率不是预热导致的，更可能是上述资源限制或配置问题。

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