Hi Rajendra,
To calculate the memory is called as Memory Sizing.
This depends on Size of Tables, Compression that is exerted on the tables stored & Extra working memory (Need to know the tables sizes first, it will show that if we have large tables then the result of operation between these large tables too can be large)
Dynamically allocated memory consists of Heap and Shared Memory.
But it is not easy to calculate the Shared Memory as it is displayed inaccurately for the following reason.
Shared Memory is a memory which is shared between two processes for information exchange by writing to this memory location. It is not easy to account for the shared memory. Does it belong to one of the process or both or neither so if we naively sum the memory belonging to multiple processes we grossly over count.
Linux reports shared memory inconsistently. When you ask it to report the resident memory map of a single process, it will report the shared-memory as part of its memory footprint. However, when you ask "how much total memory is resident", it does not account for shared memory.
This is usually not significant, because very few programs use large blocks of shared memory. However, SAP HANA is different. An early SAP HANA design decision was to use "shared memory" for row-store tables . As a result, when you use large row-store tables, the shared-memory footprint of SAP HANA can become very large.
Thus, if you ask Linux to report the resident size of SAP HANA and the total resident size on the host, the size of SAP HANA may appear to exceed the total, which of course makes no sense.
To compensate, SAP HANA adds the resident size of the shared-memory part of the SAP HANA processes to the resident size reported by Linux. This is another intentional reason why SAP HANA may report different values than Linux.
Regards,
Mahaveer Jain