So this happened today during an ETL.
A quick look through the InterTubes tells me that SSIS should spool buffers to disk only if
- memory allocation failed
- low memory resource notification sent by Windows OS
So the server had plenty of free RAM. But NUMA node 1 was in a pinch. And SSIS spooled its buffers to disk. Doggone it.
I guess I'd figured that notifications were sent based on server-wide memory state. But I guess maybe memory state on each NUMA node can lead to a memory notification?
The target SQL Server instance, a beefy one, was also on this physical server. There's 1.5 TB of RAM on the server. :-)
We lowered max server memory by 100GB, hoping to get a reasonable amount of free memory on NUMA node 1 for tomorrow's ETL. (The server was also rebooted for an unrelated reason.)
I dunno though. This is SQL Server 2014 SP1 CU2.
Memory is already being consumed unevenly across the NUMA nodes. If NUMA node 1 gets short end of the stick by 6:00 am tomorrow, I think for now we may try to affinitize SSIS to NUMA node 2, in hopes that its memory allocations will come from that node and it that memory allocations will continue to allow enough free memory there even while short-changing NUMA node 1.
A blog post showing use of Windows Resource Manager to affinitize SSIS. But... this feature was deprecated in Windows Server 2012 R2.
:-( Sad trombone.
Maybe next version of SSIS can support affinity natively, similar to SQL Server database engine? Or maybe SSIS can be made NUMA aware? Or...
Well, at any rate, for maximum scalability and flexibility, gotta find some way of making this work...