Determining Physical Memory Requirements Based on Parameters

[Former Member]

Hi,

I was wondering if there's a way to calculate / determine the lowest required physical memory on a system based on the profile settings of an ABAP instance.

In this case ST06 shows that we are 95% utilized for physical memory, but free -m on the system doesn't agree.

Does ST06 take virtual memory into account where it says "physical", or does it actually take physical memory (i.e., cached + buffered by the kernel) into account?

Is there a way you can take the parameters set on the system and say if there is, or isn't enough memory to support the application + the base OS?

abap/buffersize	=	1800000
abap/heap_area_dia	=	2000683008
abap/heap_area_nondia	=	2000683008
abap/heap_area_total	=	2000683008
abap/heaplimit	=	40894464
abap/swap_reserve	=	20971520
abap/use_paging	=	0
em/blocksize_KB	=	4096
em/global_area_MB	=	255

ztta/roll_area	=	6500352
ztta/roll_extension	=	2000683008
ztta/roll_first	=	1
ztta/short_area	=	4000000

would the above be enough to determine minimum amount of physical memory?

[Former Member · Accepted solution]

Hello Ben,

I would assume that the 'sappfpar' command on operating system level should provide what you are looking for in an ABAP system:

As user <sid>adm call 'sappfpar check pf=<path to instance profile>'

e.g. as user npladm:

sappfpar check pf=/usr/sap/NPL/SYS/profile/NPL_DVEBMGS42_nplhost

This creates a list and at its end it gives an estimation about the "swap space requirements". Although this might be misleading in this context, the so called "worst case requirement" is the amount of memory the ABAP system could allocate against the operating system if all quotas are exhausted.

In my NPL example:

"

Swap space requirements estimated

================================================

Shared memory....................: 1140.6 MB                           (these are SAP buffers,

..in pool 10  126.4 MB,   97% used                                      see transaction st02 as reference)

..in pool 40  104.1 MB,   97% used

..not in pool:  904.1 MB

Processes........................:  166.3 MB

Extended Memory .................: 4096.0 MB                         (value of parameter em/initial_size_MB)

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

Total, minimum requirement.......: 5402.9 MB                    (sum of the above mentioned)

Process local heaps, worst case..: 1907.3 MB                   (abap/heap_area_total = 2000000000)

Total, worst case requirement....: 7310.2 MB                    (sum plus maximum Heap)

"

Regarding the discrepancy between operating system and SAP values, please also have a look at SAP note 1382721 - Linux: Interpreting the output of the command 'free'.

Best Regards,

Alexander.

[Former Member · Accepted solution]

Thank you Alexander. Based on the sappfpar it seems as though our minimum and worst case are near / at the level of our memory + swap.

This is based on Extended Memory 2 requirements as the VM container requirements are super inflated.

Thank you for the note on the free command.. I've explained it to the teams many times, but it'll be settle in much better now that it comes from SAP as their source.

Do you have experience with tuning the parameters for EM2? Do you have the pure calculation handy (i'll be looking around in sdn after I hit reply).

Thank you again.

[Former Member · Accepted solution]

Hello Ben,

as you have already seen, sappfpar does also take the amount of EM2 into account when displaying the needed resources.

I am sorry, but for further information and configuration I can only recommend to you to have a look at the VM Container memory management documentation on help.sap.com.

Best Regards,

Alexander.

[Former Member · Accepted solution]

Alexander,

Thank you for the help. I found that we were not using the VM Containers. I saw them because of the sappfpar I was running.

It seems that SAP does a hard check based on physical memory, so I added some memory and we were able to increase the EM as expected.

It's strange though, at the physical layer the VM is not using much memory even though the Extended Memory in SAP is filling up. I'm guessing it's not very good at deleting / releasing the memory segments that gets allocated with EM.

Oh well.