SAP HANA, across its different processes, reserves a pool of memory before actual use. This pool of allocated memory is preallocated from the operating system over time, up to a predefined global allocation limit, and is then efficiently used by SAP HANA as needed.
SAP HANA preallocates and manages its own memory pool, used for storing in-memory table data, thread stacks, temporary results, and other system data structures. When more memory is required for table growth or temporary computations, the SAP HANA memory manager obtains it from the pool. When the pool cannot satisfy the request, the memory manager increases the pool size by requesting more memory from the operating system, up to a predefined allocation limit.
By default, the allocation limit is calculated as follows: 90% of the first 64 GB of available physical memory on the host plus 97% of each further GB.
There is normally no reason to change the value of this variable, unless you purchased a license for less than the total amount of physical memory. In this case, you need to change the global allocation limit to remain in compliance with the license.
Another case in which you may want to limit the size of the memory pool is on development systems with more than one SAP HANA system installed on a single host. This will avoid resource contentions or conflicts.
Service Allocation Limit
In addition to the global allocation limit, each service running on the host has an allocation limit, the service allocation limit. Given that collectively, all services cannot consume more memory than the global allocation limit, each service has what is called an effective allocation limit. The effective allocation limit of a service specifies how much physical memory a service can in reality consume given the current memory consumption of other services.
What happens when the allocation limit is reached?
Memory is a finite resource. Once the allocation limit has been reached and the pool is exhausted, the memory manager can no longer allocate memory for internal operations without first giving up something else. Buffers and caches are released, and column store tables are unloaded, column by column, based on a least-recently-used order, up to a preset lower limit. When tables are partitioned over several hosts, this is managed on a host-by-host basis; that is, column partitions are unloaded only on hosts with an acute memory shortage.
Table (column or partition) unloading is generally not a good situation since it leads to performance degradation later when the data will have to be reloaded for queries that need them. You can identify pool exhaustion by examining the M_CS_UNLOADS system view.
However, it is still possible that the memory manager needs more memory that it is available. For example, when too many concurrent transactions use up all memory, or when a particularly complex query performs a cross join on very large tables and creates a huge intermediate result that exceeds the available memory. Such situations can potentially lead to an out-of-memory failure.
