Memory settings in Analysis Services might be an important tuning of a correct setup, both for production and developer machines. Analysis Services 2012 can be installed in different ways and the new Tabular instance has new memory settings that are important to know.
I expect that many servers (and developer’s workstations) will have at least two instances: one for BISM Multidimensional and the other for BISM Tabular. A Multidimensional has all the memory settings that were already in previous versions of Analysis Services. You can find more info about Memory Properties on MSDN Books On Line. In case you have more instances running on the same machine, you might want to consider altering the default settings, especially on a production machine where the two instances are used concurrently (it might be less important on a developer workstation where only one of the two instances is used at a particular time).
The more important settings (including their default value) are:
- Memory / HardMemoryLimit – 0
- Memory / LowMemoryLimit – 65
- Memory / TotalMemoryLimit – 80
A Tabular instance shares these same settings and adds new properties that are specific to the Vertipaq engine:
- Memory / VertiPaqMemoryLimit – 60
- Memory / VertiPaqPagingPolicy – 0
The value of VertiPaqPagingPolicy defines how paging works with Tabular.
- Mode 0 – Locked – Lock all VertiPaq data in memory
- Mode 1 – Allow system paging – Lock only hash dictionaries in memory, and allow VertiPaq data to exceed total physical memory
In case you choose mode 0, the VertiPaqMemoryLimit defines the total amount of memory VertiPaq is allowed to lock in the working set (and hence the total that can be used for in-memory databases – remember that the Analysis Services service might use more memory for other reasons). In mode 1, it defines a limit for the physical memory that is used by VertiPaq, allowing paging for the remaining memory (virtual committed memory) above this limit.
The VertiPaqPagingPolicy setting provides a way to prevent VertiPaq data from interacting badly with the memory cleaning subsystem. In mode 1, it causes the cleaner subsystem to ignore memory allocated for VertiPaq data beyond VertiPaqMemoryLimit when calculating the price of memory. In this mode, the server’s total memory usage will be permitted to exceed physical memory, constrained primarily by total virtual memory, paging data out to system pagefile.
If you want to reduce memory for an instance of Analysis Services, it makes sense to set VertiPaqMemoryLimit to a number that is lower than LowMemoryLimit.
Now, some more details about other memory settings in Tabular and their interaction with VertiPaqPagingPolicy and VertiPaqMemoryLimit regarding to cache eviction in VertiPaq. A big thank you to Brad Daniels and Akshai Mirchandani for sharing many details you can find in this article.
HardMemoryLimit is the maximum memory the system can ever have. If SSAS exceed the hard memory limit, the system will aggressively kill active sessions in order to reduce memory usage. Sessions killed for this reason will receive an error about being cancelled due to memory pressure. In PowerPivot or BISM mode with a VertiPaqPagingPolicy other than 0, it is also the limit for the maximum working set of the process. If HardMemoryLimit is set to 0, it will use a default value of midway between the high memory limit and total physical memory (or total virtual address space, if you’re on a 32 bit machine where physical memory exceeds virtual memory).
TotalMemoryLimit is the high memory limit – it is used to calculate the memory price for normal cache eviction and memory cleaning. If it exceeds the total memory limit, the memory manager will evict all cached data which is not currently in use. TotalMemoryLimit must always be less than HardMemoryLimit.
LowMemoryLimit is the point where the system will begin cleaning memory out of caches. As memory usage increases above the low memory limit, SSAS get more aggressive about evicting cached data until it hits the high/total memory limit, at which point it evicts everything that isn’t pinned.
Since cache eviction decisions and hard limit enforcement are normally done based on the process’s total memory usage, it has been necessary to change that calculation when allowing databases to exceed physical memory. Therefore, when VertiPaqPagingPolicy is nonzero, indicating that memory can grow beyond total physical, the system will track the total memory used by VertiPaq as a separate quantity (as reported in the MemoryVertiPaq* counters), and if the total memory used by VertiPaq exceeds the VertiPaqMemoryLimit, the memory used by VertiPaq in excess of the limit will be ignored for the purposes of determining what to evict.
For example, say VertiPaqMemoryLimit is 100GB, LowMemoryLimit is 110GB, and TotalMemoryLimit is 120GB. Now assume that VertiPaq data structures are using 210GB of memory, and the process’ total memory usage is 215GB. This number is well above the TotalMemoryLimit (and probably above HardMemoryLimit), so ignoring VertiPaqMemoryLimit, the cleaning would be very aggressively, and would kill sessions. However, when PagingPolicy is 1, the memory used by VertiPaq in excess of the limit is ignored for the purpose of computing memory pressure. This means that the number used is <Total Memory> (215GB) – <Total VertiPaq Memory>(210GB) + <VertiPaqMemoryLimit>(100GB) = 105GB, which is below the LowMemoryLimit, so the cache is not cleaned at all.