HANA "Used" vs "resident" memory

[Former Member]

Hello everyone,

As I was trying hard to grasp the HANA memory concepts this most confusing statement came up:

-----------------------------------------------------------------------------------------------------------------------------------------------------------

When memory is required for table growth or for temporary computations, the SAP HANA code obtains it from the existing memory pool. When the pool cannot satisfy the request, the HANA memory manager will request and reserve more memory from the operating system. At this point, 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, usually without informing Linux6. 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 to below the size of SAP HANA’s resident memory, which is perfectly normal.

----------------------------------------------------------------------------------------------------------------------------------------------------

So I made a little scheme to demonstrate to myself how on earth this happens. Can somebody check my logical thinking and tell me if I am on the right way?

1. So in the first step, memory manager grabs more space from the overall free space (when HANA's "pool cannont satisfy the request". This results in increase HANA's resident memory

2. Now when the memory is no longer needed, the memory manager returns this space back into the free pool but "without informing Linux6".

So because OS does not know that it got thee memory back, it sees the HANA's resident memory more than it actually is, while from HANA's perspective it's pool got shrinked back to it's original size.

IS THAT HOW IT WORKS?

please help

[lbreddemann · Accepted solution]

Yep, that's roughly how that works.

SAP HANA assumes it is the only major application on the server (if not configured otherwise) and releasing memory back to the OS is terribly expensive. So, SAP HANA doesn't do it if somehow avoidable.

- Lars

[Former Member]

This is the normal situation: The SAP HANA allocated memory (and as a consequence the resident memory) can be significantly higher than the SAP HANA used memory. If you run SQL: "HANA_Memory_Overview" (SAP Note 1969700), you can pretty well compare used and allocated memory (and some more stuff). See also SAP Note 1999997 for more information about SAP HANA memory.

[Former Member]

Pretty much what you just said, with a little more detail.

There are three key concepts that could help clarify this.

Virtual memory - the amount of memory linux assigns to a process; this can grow as a process requests more memory.

Resident memory -  the amount of virtual memory currently in physical memory; This can fluctuate if the OS swaps to make room for other code or data used by a process; Shouldn't happen because HANA should have enough mem that swapping won't be required.

Used memory - the amount of memory currently in use by code, data, etc.; Also fluctuates.

When a process requires memory, HANA will fetch it from the existing virtual memory pool. If the process requires more than is available, then HANA will grab from the OS. This means the virtual memory pool will grow.

When resident or used memory shrinks, the memory goes back to the virtual memory pool. HANA doesn't release memory from the virtual mem back to the OS, so the virtual memory pool will not shrink.

So memory can be "freed" to the virtual memory pool, but only for the particular process to use.

[kilian_kilger]

Hi,

I am certainly not an expert on HANA's memory management. But from your picture it looks like HANA is leaking memory, which it certainly is not.

I assume that HANA is not giving back the memory the the OS because it may reuse it later on. But HANA doesn't forget about this memory for sure. That's actually a very common pattern, which nearly all applications written in C/C++ use. The ABAP does similar things at many occasions.

Best regards,

Kilian.