SSIS 缓冲区/内存故障

Question

运行 SSIS 包时出现此错误...

分配 104857600 字节时缓冲区失败。系统报告31% 的内存负载。有 17179328512 字节的物理内存，其中 11714314240 字节空闲。有 2147352576 字节的虚拟内存，其中 406519808 字节空闲。分页文件有 19729465344 字节，其中 13419847680 字节空闲。

运行包的机器上的内存似乎没问题。31% 的内存负载被认为是高吗？这仅在迁移到较新的服务器后才开始发生。但是这个新服务器的内存容量增加了一倍。

没有添加新的 SSIS 包。SSIS 包存储在 SQL Server 2008R2 服务器上。它们是从另一台运行 SSIS 2008 的服务器调用的。

知道是什么原因造成的吗？

SSIS 包通过第 3 方应用程序执行。我们强制此应用程序以 32 位运行，因为在添加对 System.Data.dll 的引用后出现以下错误

如何强制 SSIS 包以 64 位运行？

Answer 1

2,147,352,576 字节是 2Gb，这意味着您有一个在 32 位 Windows 上运行的 32 位 SSIS，因此 16Gb 总内存（其中 10.9 是免费的）相当没有意义，但 31% 来自：(17,179,328,512 - 11,714,314,240) / 17,179,328,512 = 0.318。

A 32-bit process can only use 2GB (or under some configurations 3Gb) unless it is compiled LARGEADDRESSAWARE and running on a 64-bit edition of Windows. On 64-bit Windows a large-address aware process should be able to use 4Gb (see this which refers to here).

In this case the process seems to have ~386Mb available in the 2GB address space and is failing to allocate 100Mb which is less than that - one educated guess is that this could be due to fragmentation: if SSIS is wanting a single coherent block and the remaining free address space is in blocks smaller than that spread around the address space.

No new SSIS packages have been added.

The change is likely due to increases in incoming data size in that case.

Possible Solutions

If you are running a 32-bit Windows edition you could try using the /3GB switch to ask Windows to use the 3+1 address space arrangement for 32 bit processes instead of 2+2 (see https://technet.microsoft.com/en-us/library/bb124810(v=exchg.65).aspx or similar reference for your edition of Windows) - if SSIS is capable of using the larger address space this will give it a bit more room.

If you are using a 64-bit Windows install and 64-bit SQL then try to make SSIS use its 64-bit run-time. There are issues with some data access drivers here though so that may not work. Also the design-time environment is always 32-bit. See https://technet.microsoft.com/en-us/library/ms141766(v=sql.105).aspx and other documentation.

In either case you may be able to break down your ETL process into smaller packages and chain them together with Execute Package tasks. With the "ExecuteOutOfProcess" option turned on each package called should be able to use its own 2Gb address space.

You might also try tweaking the way buffers are allocated in data flow tasks using the DefaultBufferMaxRows and DefaultBufferMaxSize properties; see here, here and here.