dw.sap processes do not release memory on Suse SL9

[Farid]

Hello,

We have an ecc6 Ehp4 system running on ;

• One Central instance ; Hp-ux ia64

• 6 Linux Dialog Instances ; Linux SUSE SLES9/X86_64 64BIT

More than 30 Gb of physical memory have been assigned to each Linux application servers, but

we are facing memory bottlenecks. after analysys, it turns out that some sap processes dw.sap

do not release the memory.

At the sap level, the DIA or BTC process is not running anymore.

At the OS level the corresponding dw.sap process still uses big chunk of memory

p01adm 10674 2.9 45.4% 20081372 14955448 ? S Oct03 77:58 | \_ dw.sapP01_D01 pf=/sapmnt/P01/profile/P01_D01_aor3p01a1

p01adm 20839 6.4 48.5% 20091644 15992276 ? S Oct04 121:43 | \_ dw.sapP01_D01 pf=/sapmnt/P01/profile/P01_D01_aor3p01a1

p01adm 25379 5.8 47.6% 20085096 15670868 ? S Oct04 106:47 | \_ dw.sapP01_D01 pf=/sapmnt/P01/profile/P01_D01_aor3p01a1

p01adm 29367 6.1 44.7% 20086804 14735952 ? S Oct04 110:44 | \_ dw.sapP01_D01 pf=/sapmnt/P01/profile/P01_D01_aor3p01a1

p01adm 1326 3.8 41.6% 20078600 13703268 ? S Oct04 66:53 | \_ dw.sapP01_D01 pf=/sapmnt/P01/profile/P01_D01_aor3p01a1

p01adm 21643 6.3 42.3% 20087888 13951496 ? S Oct04 98:53 | \_ dw.sapP01_D01

I had a look at SAP note 706071, but it doesn't corespond to our issue, anyone has any idea ?

thank you

Regards

Raoul

[markus_doehr2 · Accepted solution]

> * 6 Linux Dialog Instances ; Linux SUSE SLES9/X86_64 64BIT

You're aware that SLES 9 is out of support since August 2011?

Note 936887 - End of maintenance for Linux distributions

> More than 30 Gb of physical memory have been assigned to each Linux application servers, but

> we are facing memory bottlenecks. after analysys, it turns out that some sap processes dw.sap

> do not release the memory.

A SAP system uses shared memory, it's allocated on system start and not released until the system is stopped.

If you run out of memory I would suggest that you check your memory configuration.

> At the sap level, the DIA or BTC process is not running anymore.

> At the OS level the corresponding dw.sap process still uses big chunk of memory

They are attached to the shared memory segment, this is not exlusive memory.

> I had a look at SAP note 706071, but it doesn't corespond to our issue, anyone has any idea ?

Usually it's not a problem if the memory keeps being allocated if the system is properly configured. Shared memory disclaiming is available on Linux but it's not supported on your operating system.

Note 724140 - Extended memory, release for operating system

I would suggest that you first check your memory parameters, execute on an application server as user <sid>adm:

sappfpar pf=/sapmnt/<SID>/profile/<instance_profile> check

and post the output.

Markus

[Farid · Accepted solution]

Thank you Orkun and Markus for your answer,

Actually an OS upgrade of the Linux instances is planned for next year ... to be honest, I wasn't aware that we were Alreadyout of maintenance. I guess this will become a priority now.

I had a look at SAP note 724140 and I was wondering I we can still implement the shared memory disclaiming parameters, I didn't see any restriction regarding our Linux distribution ?

According to the sappfpar command output (below), there isn't any error in the way the memory is configured.

But, according to OS06 transaction and OS commands (glance, free) there is only 200 MB of free physical memory out of 33 GB of physical memory allocated.. If I understand you right, this is not necessarily a dysfuntional behaviour, since by default, the extended memory is not released to the OS.

My problem is that we need more free physical memory on the server, precisely to significantly increase some SAP memory parameters.

Nr of operating system shared memory segments: 28

Shared memory resource requirements estimated

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

Total Nr of shared segments required.....: 28

System-imposed number of shared memories.: 1000

Shared memory segment size required min..: 1073741924 (1024.0 MB)

System-imposed maximum segment size......: 18387828736 (17536.0 MB)

Swap space requirements estimated

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

Shared memory....................: 2780.6 MB

..in pool 10 131.3 MB, 74% used

..in pool 40 141.0 MB, 81% used

..not in pool: 2500.3 MB

Processes........................: 524.5 MB

Extended Memory .................: 16384.0 MB

-

---

Total, minimum requirement.......: 19689.2 MB

Process local heaps, worst case..: 1907.3 MB

Total, worst case requirement....: 21596.5 MB

Errors detected..................: 0

Warnings detected................: 2

[markus_doehr2 · Accepted solution]

> I had a look at SAP note 724140 and I was wondering I we can still implement the shared memory disclaiming parameters, I didn't see any restriction regarding our Linux distribution ?

SLES 9 has the necessary madvise() function not implemented. If you check the workprocess traces you will see that shared memory disclaiming is not supported on kernel versions of SLES 9.

> According to the sappfpar command output (below), there isn't any error in the way the memory is configured.

> But, according to OS06 transaction and OS commands (glance, free) there is only 200 MB of free physical memory out of 33 GB of physical memory allocated.. If I understand you right, this is not necessarily a dysfuntional behaviour, since by default, the extended memory is not released to the OS.

> My problem is that we need more free physical memory on the server, precisely to significantly increase some SAP memory parameters.

Linux uses all available memory for filesystem cache. So even if the free memory is down to 0 it doesn't mean that the system is under memory presure. On SLES 9 you can't configure the amount of filesystem cache that is used (the kernel just uses it all) so that is normal Linux behaviour.

> Total, minimum requirement.......: 19689.2 MB

> Process local heaps, worst case..: 1907.3 MB

> Total, worst case requirement....: 21596.5 MB

So if you have 30 GB physical memory there's no need to worry.

Markus

[Former Member · Accepted solution]

Hi,

Additionally, if you would like to insist to reclaim memory to the OS, you can evaluate to use "rdisp/wp_auto_restart" profile parameter.

Best regards,

Orkun Gedik

[markus_doehr2 · Accepted solution]

> Additionally, if you would like to insist to reclaim memory to the OS, you can evaluate to use "rdisp/wp_auto_restart" profile parameter.

I'm not sure whether the allocated shared memory segments are actually released, I'd say the WP detaches and re-attaches to them. However, restarting will help releasing the heap (process local) memory, if there was any allocated.

Markus

[Former Member · Accepted solution]

Hi Markus,

>> I'm not sure whether the allocated shared memory segments are actually released, I'd say the WP detaches and re-attaches to them. However, restarting will help releasing the heap (process local) memory, if there was any allocated.

Yes, you are correct. It will not help to reclaim shared memory to OS. But, it will be help to reclaim a portion of memory that allocated by SAP WPs, to the OS.

Best regards,

Orkun Gedik

[Former Member]

Hi,

Even if the potion of extended memory released by SAP components, from OS point of view its state will be busy. To give back this memory to the OS setup a threshold on the SAP profile parameters.

In short, when the threshold level exceeded, the memory will be released to the OS.

Check the note 724140 - Extended memory, release for operating system.

Best regards,

Orkun Gedik