Checking the Memory Usage

After completing this lesson, you will be able to:

After completing this lesson, you will be able to:

  • Check the SAP HANA system memory usage

Memory Usage

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.

Performance Monitor

Analyzing the performance of the SAP HANA database over time can help you pinpoint bottlenecks, identify patterns, and forecast requirements. Use the Performance Monitor application to visually analyze historical performance data across a range of key performance indicators related to memory, disk, and CPU usage.

The Performance Monitor opens displaying the load graph for the selected resource: CPU, disk, or memory. The load graph initially visualizes resource usage of all hosts and services listed on the left according to the default KPI group of the selected resource.

(1) Sets the monitored time frame that you want to investigate. You can set your own desired time frame or choose from the Presets menu.

(2) The Refresh rate dropdown list allows you to set the automatic screen refresh rate. The update rate can be set between two seconds and 10 minutes.

(3) The Add Chart button allows you to create custom charts displaying the host and services selection, and selected KPIs. Select new KPIs from the list of all available KPIs.

(4) Zoom into a specific time on a graph by brushing across the desired selection on the load graph directly. The highlighted area will automatically zoom in the lower chart section. Move the highlighted area by drag and drop it to another time range in the upper chart. The lower chart section will follow your choice. To zoom out again, select another spot in the upper chart. You can also compare the performance of your selected KPIs at different times using the Performance Comparison page.


It is also possible to enlarge areas in the lower chart by marking a dedicated time range and choosing the Zoom into selected time range button on the upper-right corner of the highlighted section. Choose the Undo button in the header toolbar to zoom out again.

Monitor Table Usage

In the Table Usage screen, you can monitor the resource usage of tables. You can visualize tables by size and explore the usage history of tables.

Monitor table operations to identify where you can improve performance and reduce memory utilization.

Filter Tables (1) allows you to filter by the number of times a table is accessed and the table size. You can also specify how many tables you want to see in the listing.

The bubble-chart and table-chart buttons (2) let you switch between the graphical view and the list view.

Log in to track your progress & complete quizzes