Physical memory is the DRAM memory installed on the host. On most SAP HANA hosts, it ranges from 256 gigabytes (GB) to 4 terabytes (TB) at the high end. As an in-memory database, it is important for SAP HANA to carefully manage and track its consumption of this critical resource. Therefore, all the SAP HANA servers include a memory manager, which preallocates and manages its own memory pool, up to a configurable allocation limit. This pool is used for storing tables, for thread stacks, for temporary computations, intermediate results, and other data structures. In addition to the pool, main memory is used for the program code (exclusive and shared) and stack of the SAP HANA processes.
From the Linux operating system perspective, SAP HANA is a collection of separate processes. Linux programs request and reserve memory for their use from the Linux operating system. The entire reserved memory footprint of a program is referred to as its virtual memory. Each Linux process has its own virtual memory, which grows when the process requests more memory from the operating system, and shrinks when the process relinquishes unused memory. SAP HANA employs the term used memory to indicate the portion of the virtual memory that is in current use for code, stacks, tables, and intermediate results. Viewing all SAP HANA’s processes in aggregate, the figure, SAP HANA Memory Pool: Used Memory and Virtual Memory, shows SAP HANA’s virtual and used memory.
As an in-memory database, it is crucial for SAP HANA to manage and track its own consumption of memory carefully. For this purpose, the SAP HANA database preallocates and manages its own data memory pool. The memory pool is used for storing in-memory tables, thread stacks, temporary computations, intermediate results, and other data structures. The use of memory by SAP HANA, therefore, includes its program code (exclusive and shared), the program stack, and the memory pool this includes all of the data tables (row and column), system tables, and created tables.
Parts of the pool are always in use for temporary computations. The total amount of memory in use is referred to as used memory. This is the most precise indicator of the amount of memory that the SAP HANA database uses.
Virtual, Physical, and Resident Memory
Linux manages the mapping of virtual memory to the physical memory of the host. The part of the virtual memory in physical memory is called resident memory. Resident memory is the physical memory used by a process.
Over time, the operating system may "swap out" some of a process’ resident memory, according to a least-recently-used algorithm, to make room for other code or data. Thus, a process’ resident memory size may fluctuate independently of its virtual memory size. In a properly sized SAP HANA appliance, there is enough physical memory, and thus swapping is disabled and should not be observed.
When memory is required for table growth or for temporary computations, SAP HANA obtains it from the existing memory pool. When the pool cannot satisfy the request, the SAP HANA memory manager will request and reserve more memory from the operating system. As a result, the virtual memory size of the HANA processes grows. Once a temporary computation completes or a table is dropped, the freed memory is returned to the memory manager, who recycles it to its pool, without informing Linux. Thus, from SAP HANA’s perspective, the amount of used memory shrinks, but the process’ virtual and resident sizes are not affected. This creates a situation where the used memory may even shrink below the size of SAP HANA’s resident memory, which is perfectly normal.
On a typical SAP HANA appliance, the resident part of the OS and all other running processes usually does not exceed 2 GB. The rest of the physical memory is available for the use of SAP HANA.
Memory Consumption
The figure, Memory Consumption, shows the relationship between the host’s physical memory, Linux virtual and resident memory, and SAP HANA’s memory pool and used memory indicators. Note how changes in used memory do not affect the processes’ virtual and resident sizes.
The SAP HANA database, 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. It is then efficiently used as needed by the SAP HANA database code.
Linux Memory Indicators
Since the operating system treats SAP HANA as a collection of processes, we need to consider both the virtual and resident part of these processes. A process’ virtual memory size is always larger than its resident size. Note also, that due to the managed memory pool, both the SAP HANA virtual size and resident sizes may appear larger than what the Used Memory indicator would lead you to expect. This is entirely normal.
Linux maintains high water mark (peak) indicators for the virtual and resident process sizes. In a stable system, the current virtual and resident sizes will be only slightly smaller than their respective high watermarks because SAP HANA grows its pool, but does not normally relinquish unused memory. Thus, the resident size high water mark should generally track the peak Used Memory. Very large differences may indicate that parts of the SAP HANA memory pool were freed, possibly due to insufficient physical memory.
Monitoring Memory Consumption in SAP HANA Cockpit
Selecting the Used Memory card in the SAP HANA cockpit opens the performance monitor app displaying host and service-specific memory KPIs like used memory, database used memory, allocation limit, and so on, and a load graph. The load graph initially visualizes memory usage on the coordinator host and coordinator index server. You can customize it to your needs.
