Azure Synapse Pipeline批量处理文件挂起/内存溢出问题排查求助

核心问题分析 #

从报错System.OutOfMemoryException和卡住任务的输出来看，问题根源是集成运行时（IR）内存资源耗尽：批量处理数百个文件时，内存占用累积超过IR的可用上限，导致部分Copy任务无法完成写入（dataWritten=0但rowsCopied已完成），最终任务被取消；小批量（25个文件）时内存占用未达阈值，因此运行正常。

具体解决思路 #

1. 升级集成运行时（IR）规格 #

• 如果使用自托管IR：直接升级运行IR的服务器内存（建议至少16GB以上，根据文件数量和大小调整），同时关闭服务器上其他占用内存的进程。
• 如果使用托管IR：将IR规格从通用型（General Purpose）切换为内存优化型（Memory Optimized），或提升实例级别（比如从v2系列升级到v3系列），增加IR的内存配额。

2. 限制任务并行度 #

• For Each活动：将Sequential设置为True，改为串行执行；若需要并行，降低Batch Count（默认10），比如设置为5，避免同时运行过多Copy任务导致内存叠加耗尽。
• Copy活动：保持usedParallelCopies=1即可，无需提升，避免单任务内存占用过高。

3. 优化Copy活动的内存占用 #

• 分块读取大文件：针对FileServer源，在Copy活动的源配置中添加chunkSize参数（比如设置为10485760即10MB），让系统分块读取文件，避免一次性加载整个文件到内存。
• 调整压缩文件处理：对于.gz压缩文件，若业务允许，可先在源端解压后再处理；若必须在管道中解压，确保IR有足够内存（解压后的文件大小通常是原压缩文件的3-10倍）。
• 关闭不必要的验证：若业务对数据一致性要求不高，可关闭Copy活动的Data Consistency Verification，减少内存占用。

4. 拆分任务批次 #

• 不要一次性处理1588个文件，拆分多个批次：
  1. 用Lookup活动获取所有待处理文件的列表；
  2. 按文件数量（比如每200个一批）或文件总大小（比如每500MB一批）拆分列表；
  3. 分批次触发管道运行，避免长时间运行导致IR内存泄漏或累积占用。

5. 深入排查日志与监控 #

• 查看IR日志：自托管IR的日志路径为C:\Program Files\Microsoft Integration Runtime\5.0\Shared\Log，搜索内存相关的警告/错误，确认内存耗尽的具体时机。
• 分析Copy详细日志：访问logFilePath中的日志文件，查看写入阶段是否有隐藏的网络或内存相关错误（即使任务输出errors为空，详细日志可能有更多信息）。
• 监控IR资源使用率：在Azure门户中查看IR的CPU、内存使用率，确认任务运行时内存是否达到100%，验证内存瓶颈的判断。

6. 优化Sink端写入配置 #

• 检查网络连接：确保FileServer源与Azure BlobFS Sink的网络连接稳定（比如使用VPN或ExpressRoute），避免网络超时导致任务卡住。
• 减小写入批次：调整Copy活动的writeBatchSize参数（比如从默认的10000改为5000），降低单次写入的数据量，减少内存占用。

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