The following type of memory areas are most important:
|Physical memory||operating system||global||Total amount of memory physically available on host level (typically RAM)|
|Virtual memory||operating system||process||Total amount of memory allocated by all processes held both in physical memory and in paging area on disk.
SAP HANA virtual memory is the maximal amount that the process has been allocated, including its reservation for code, stack, data, and memory pool under program control. SAP HANA Virtual Memory dynamically growth when more memory needed (eg: table growth, temp computation and etc).
|Resident memory||operating system||process||Total amount of memory allocated by all processes held in physical memory, large allocations are usually fine (SAP Note 2081473)|
|Allocated memory||SAP HANA||process||Total amount of memory allocated by the SAP HANA processes, limited by the configurable SAP HANA global allocation limit. Less relevant for SAP HANA memory analysis because allocated, but unused memory can be re-used when required|
|Used memory||SAP HANA||process||Total amount of memory in use by the SAP HANA processes, relevant to understand SAP HANA memory footprint. This is the most precised indicator of the amount of memory that SAP HANA requires at any time.|
|Shared memory||SAP HANA||global||Memory that can be accessed by different processes, e.g.: Specific row store components (tables, catalog, free),Nameserver topology|
|Heap memory||SAP HANA||process||Memory exclusively accessible by threads of a single process (e.g. indexserver), e.g.: Column store,Row store indexes,Intermediate results,Temporary structures,SAP HANA page cache|
In normal SAP HANA environments no paging happens and SAP HANA is the only major memory allocator on the host. The following conditions are typically met:
“Physical memory > virtual memory
Virtual memory = resident memory >= allocated memory
Allocated memory = shared memory + allocated heap memory
Used memory = shared memory + used heap memory
Code, stack: Usually negligible sizes”
Normally the allocated memory should be fully contained in the resident memory, nevertheless there are a few exceptions:
If parts of the virtual memory are paged out to disk, the resident memory can be smaller than the allocated memory.
There are technical constellations where parts of the heap memory and the row store shared memory are marked as used, but not as resident.
The following illustration shows the relationship between physical memory, Linux virtual and resident memory,and SAP HANA’s pool and used memory indicators.
Note how changes in Used Memory (due to query execution do not affect the processes’ virtual and resident sizes).
For efficiency reasons SAP HANA frees allocated memory in a “lazy” way and so the allocated memory can grow up to the available memory and the global allocation limit while the used memory remains at a much lower level.
From a memory analysis perspective we can usually focus on the used memory and assume that the allocated memory is released whenever required.
The following picture illustrates the general SAP HANA memory structure:
Hope it will cover explain the basic memory structure of SAP HANA.
For more detail you can refer KBA 1999997.