Forum Discussion
SSAS model loading ends in memory failure
jacccodezwart ok, If the msmdsrv.ini memory settings are identical, then we can probably rule out a simple misconfiguration. That means the issue on Server 2 is more likely tied to the environment rather than the model itself.
Here are the next things I’d look into:
NUMA & Hardware Layout
-
Large memory servers often have multiple NUMA nodes, and the VertiPaq engine needs large contiguous memory blocks.
-
On a machine with “too much” memory, allocations can fragment across NUMA nodes and fail even though plenty of memory is technically available.
Try starting SSAS with processor affinity limited to a single NUMA node.
-
Start the SSAS service.
-
Open Task Manager → Details tab.
-
Find msmdsrv.exe, right-click → Set affinity.
-
Choose CPUs belonging to only one NUMA node (e.g., CPUs 0-7 if your first node has 8 cores).
-
Re-run processing.
BBF
💡 Did I answer your question? Mark my post as a solution!
👍 Kudos are appreciated
🔥 Proud to be a Super User!
-
jacccodezwart Hi!
It could be a memory limit at SSAS instance level
-
SSAS Tabular doesn’t just use “all available memory.”
-
Check VertiPaqPagingPolicy and Memory* properties in msmdsrv.ini (typically in C:\Program Files\Microsoft SQL Server\MSAS15.<instance>\OLAP\Config\).
-
LowMemoryLimit, TotalMemoryLimit, HardMemoryLimit are percentages of physical memory, not fixed GB values.
-
If Server 2 has more memory but these are misconfigured (too restrictive), SSAS may self-throttle and fail.
-
Compare msmdsrv.ini between the servers. Don’t assume the setup wizard chose the same defaults.
BBF
💡 Did I answer your question? Mark my post as a solution!
👍 Kudos are appreciated
🔥 Proud to be a Super User!
BeaBF Did the check this morning, but there is no difference between the two systems.
jacccodezwart ok, If the msmdsrv.ini memory settings are identical, then we can probably rule out a simple misconfiguration. That means the issue on Server 2 is more likely tied to the environment rather than the model itself.
Here are the next things I’d look into:
NUMA & Hardware Layout
-
Large memory servers often have multiple NUMA nodes, and the VertiPaq engine needs large contiguous memory blocks.
-
On a machine with “too much” memory, allocations can fragment across NUMA nodes and fail even though plenty of memory is technically available.
Try starting SSAS with processor affinity limited to a single NUMA node.
-
Start the SSAS service.
-
Open Task Manager → Details tab.
-
Find msmdsrv.exe, right-click → Set affinity.
-
Choose CPUs belonging to only one NUMA node (e.g., CPUs 0-7 if your first node has 8 cores).
-
Re-run processing.
BBF
💡 Did I answer your question? Mark my post as a solution!
👍 Kudos are appreciated
🔥 Proud to be a Super User!
BeaBF I have looked at the mentioned parameters and settings. The are the same on the test server and production server.
BUT . . . I found out that MS-SQL Server was consuming almost all the memory when running. So when SSAS starts loading data, there was little memory left to process the data model in the tabular model.
So when lowering the assigned memory amount to SQL Server, memory came available on the server for SSAS to proces the model.
-