Linux kernel parameters

[Former Member]

Hi all,

We are frequent memory issues where the utlisation has shot drastically and freezes the system.

Whats the ideal size to be maintained for the below parameters.Are these parameters the culprits for high utlisation when everythign at the SAP and DB looks fine.

/proc/sys/kernel/shmall = 5242880

/proc/sys/kernel/shmmax = 23136829430

red hat release 4 and oracle 10g.Thanks.

[former_member189546]

Hello,

Do you have this parameter set?

STD implementation (es/implementation=std)

regards,

John Feely

[Former Member]

Hi,

What major difference does it make if we have parameter set to std.Thanks.

[markus_doehr2]

> What major difference does it make if we have parameter set to std.Thanks.

It's a different memory allocation - read

Note 941735 - SAP memory management for 64-bit Linux systems

Markus

[Former Member]

Hi Markus,

Thanks for the response.

es/implementation is not set in our profiles and in rz11 it is shown as map and according to the note the defualt would be map since my kernle ersion is 7.0

[former_member189546]

hello,

Check note...

941735 SAP memory management for 64-bit Linux systems

regards,

John Feely

[markus_doehr2]

> We are frequent memory issues where the utlisation has shot drastically and freezes the system.

Before changing any kernel parameters I'd try ot figure why the system is runnign out of memory.

Check your database memory parameters as well as the instance memory parameters.

Markus

[Former Member]

Hi Markus,

Your response is really appreciated.The instance and database parameters look fine.After thorough glance had to zero down to the kernel parameters.Thanks.

[markus_doehr2]

Linux kernel parameters define limits, they don't help if the machine get into a swap race. The cause of that has to be found.

Check parameters em/initial_size_MB and PHYS_MEMSIZE and add the database memory parameters to that. If the number is higher than your physical memory (excluding swap) then you have to reconfigure.

Markus

[Former Member]

Markus,

Thanks for the response again.

SQL> show sga

Total System Global Area 729808896 bytes

Fixed Size 2099136 bytes

Variable Size 444598336 bytes

Database Buffers 281018368 bytes

Redo Buffers 2093056 bytes

SQL> show parameter pga

NAME TYPE VALUE

-

---

-

---

-

---

pga_aggregate_target big integer 372957511

em/initial_size_MB = 1872

free -m

total used free shared buffers cached

Mem: 3774 3706 68 0 225 2093

-/+ buffers/cache: 1387 2386

Swap: 20479 3083 17396

This is how memory distrubuted.Are the parameters os kernel ones not resposible for memory usage.Thanks.

[markus_doehr2]

> Total System Global Area 729808896 bytes

> em/initial_size_MB = 1872

> Mem: 3774 3706 68 0 225 2093

So it seems you have 3,7 GB usable physical RAM.

Your database uses 700 MB and initially you use 1872 MB for the system initially. That is the roughly 2,5 GB. That means that for the actual SAP data there's 1,2 GB left. Now we have to check your SAP buffers too.

please execute

sappfpar pf=<instanceprofile> check

and post the output.

Markus

[Former Member]

Hi Markus,

Apologies for the delayed response.Pasted the output of the sappfpar check.

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

== Checking profile: SID_DVEBMGS68_hostname

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

Shared memory disposition overview

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

Shared memory pools

Key: 10 Pool

Size configured.....: 152000000 ( 145.0 MB)

Size min. estimated.: 148139648 ( 141.3 MB)

Advised Size........: 152000000 ( 145.0 MB)

Key: 40 Pool for database buffers

Size configured.....: 162000000 ( 154.5 MB)

Size min. estimated.: 158351040 ( 151.0 MB)

Advised Size........: 162000000 ( 154.5 MB)

Shared memories inside of pool 10

Key: 11 Size: 500000 ( 0.5 MB) Factory calender buffer

Key: 12 Size: 6000000 ( 5.7 MB) TemSe Char-Code convert Buf.

Key: 13 Size: 60500000 ( 57.7 MB) Alert Area

Key: 14 Size: 20000000 ( 19.1 MB) Presentation buffer

Key: 16 Size: 22400 ( 0.0 MB) Semaphore activity monitoring

Key: 17 Size: 11116480 ( 10.6 MB) Roll administration

Shared memories inside of pool 40

Key: 42 Size: 12512992 ( 11.9 MB) DB TTAB buffer

Key: 43 Size: 64574392 ( 61.6 MB) DB FTAB buffer

Key: 44 Size: 13374392 ( 12.8 MB) DB IREC buffer

Key: 45 Size: 6206392 ( 5.9 MB) DB short nametab buffer

Key: 46 Size: 20480 ( 0.0 MB) DB sync table

Key: 47 Size: 8193024 ( 7.8 MB) DB CUA buffer

Key: 48 Size: 500000 ( 0.5 MB) Number range buffer

Key: 49 Size: 2968344 ( 2.8 MB) Spool admin (SpoolWP+DiaWP)

Shared memories outside of pools

Key: 1 Size: 2500 ( 0.0 MB) System administration

Key: 2 Size: 6253276 ( 6.0 MB) Disp. administration tables

Key: 3 Size: 13714400 ( 13.1 MB) Disp. communication areas

Key: 4 Size: 517648 ( 0.5 MB) statistic area

Key: 6 Size: 532480000 ( 507.8 MB) ABAP program buffer

Key: 7 Size: 14838 ( 0.0 MB) Update task administration

Key: 8 Size: 268435556 ( 256.0 MB) Paging buffer

Key: 9 Size: 583270500 ( 556.2 MB) Roll buffer

Key: 18 Size: 3670116 ( 3.5 MB) Paging adminitration

Key: 19 Size: 50000000 ( 47.7 MB) Table-buffer

Key: 30 Size: 27648 ( 0.0 MB) Taskhandler runtime admin.

Key: 31 Size: 4806000 ( 4.6 MB) Dispatcher request queue

Key: 33 Size: 20480000 ( 19.5 MB) Table buffer, part.buffering

Key: 34 Size: 33554432 ( 32.0 MB) Enqueue table

Key: 41 Size: 25010000 ( 23.9 MB) DB statistics buffer

Key: 51 Size: 3200000 ( 3.1 MB) Extended memory admin.

Key: 52 Size: 40000 ( 0.0 MB) Message Server buffer

Key: 54 Size: 8396800 ( 8.0 MB) Export/Import buffer

Key: 55 Size: 8192 ( 0.0 MB) Spool local printer+joblist

Key: 57 Size: 1048576 ( 1.0 MB) Profilparameter in shared mem

Key: 58 Size: 4096 ( 0.0 MB) Enqueue ID for reset

Key: 62 Size: 377487360 ( 360.0 MB) Memory pipes

Key: 63 Size: 409600 ( 0.4 MB) ICMAN shared memory

Key: 64 Size: 4202496 ( 4.0 MB) Online Text Repository Buf.

Key: 65 Size: 8396800 ( 8.0 MB) Export/Import Shared Memory

Key: 1002 Size: 400000 ( 0.4 MB) Performance monitoring V01.0

Key: 58900168 Size: 4096 ( 0.0 MB) SCSA area

Nr of operating system shared memory segments: 29

Shared memory resource requirements estimated

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

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

System-imposed number of shared memories.: 1000

Shared memory segment size required min..: 583270500 ( 556.2 MB)

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

Swap space requirements estimated

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

Shared memory....................: 2157.1 MB

..in pool 10 141.3 MB, 97% used

..in pool 40 151.0 MB, 97% used

..not in pool: 1855.7 MB

Processes........................: 349.2 MB

Extended Memory .................: 5968.0 MB

-

---

Total, minimum requirement.......: 8474.3 MB

Process local heaps, worst case..: 1907.3 MB

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

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

Warnings detected................: 0

[Former Member]

Hi Markus,

I had one doubt.Is extended memory not allocated as a shared memory whereas i can see other SAP buffers as a shared memory key in sappfpar.Thanks.

[markus_doehr2]

So all in all you configured your system as if you had roughly 8 GB RAM - which you don't have. And this is just for the SAP application server (as you can see), the database needs memory too.

You have to reconfigure the system or better add memory.

Markus

[Former Member]

Hi Markus,

Good Day!

sappfpar shows as 8 gb.Can we downgrade some of the memory parameters to a lower level so that memory requirement comes down 4 gb.If ye which parameters do you think needs a reduction.Thanks.

[markus_doehr2]

> sappfpar shows as 8 gb.Can we downgrade some of the memory parameters to a lower level so that memory requirement comes down 4 gb.If ye which parameters do you think needs a reduction.Thanks.

There's not much you can do. 4 GB is VERY VERY low for an ERP system.

To keep it working in physical memory you'd need reduce even more than to 4 GB (remember, the database uses 1,7 GB too plus operating system).

You could e. g. reduce abap/buffersize but this will lead to more swaps in ST02 and hence slowing down system performance.

Add more memory, that's the way to go.

Markus

[Former Member]

Hi Markus,

I had one doubt.You had told abap/buffersize is that referring to program buffer or else which one.

If there are no users logged in then extended memory would not be used right.Why is that extended memory not part of the pools.

Markus the problem with ram increasing that its a VM and we dont have any free ram available to add to this vm this was the reason given by the os team.4 gb is really very low considering our laptops run at 6and 8 gb ram nowadays.Thanks.

[Former Member]

Some amount of swaps in program buffer and export import buffer are acceptable right.Thanks

[markus_doehr2]

> I had one doubt.You had told abap/buffersize is that referring to program buffer or else which one.

yes

> If there are no users logged in then extended memory would not be used right.Why is that extended memory not part of the pools.

Check

http://help.sap.com/saphelp_nw70ehp1/helpdata/en/49/325d4ee93934ffe10000000a421937/frameset.htm

Why do you think that would make a difference?

> Markus the problem with ram increasing that its a VM and we dont have any free ram available to add to this vm this was the reason given by the os team.4 gb is really very low considering our laptops run at 6and 8 gb ram nowadays.Thanks.

Yes, I wouldn't set up such a system.

Markus

[Former Member]

Hi Markus,

I am not clear with the concept of the extended memory not in pool and getting allocated even though the users are not logged in.

Can you please help me in understanding the same.Thanks a million.

[markus_doehr2]

> I am not clear with the concept of the extended memory not in pool and getting allocated even though the users are not logged in.

> Can you please help me in understanding the same.Thanks a million

Did you check the link I posted? There is explained how a SAP system allocates memory.

Markus

[Former Member]

I had gone through but couldnt come to conclusion for the questions.Thanks.

[markus_doehr2]

It explains how memory is allocated during a system start. The question why it's done that way is not answered, right. You'd have to open an OSS call and ask the developers.

Extended memory is allocated during startup, it is not used but it's allocated.

Markus

[Former Member]

Hi Markus,

Thanks a ton for the response.As of now i am ok with how its done.

One last doubt is that why extended memory not part of the pool.Thanks.

[markus_doehr2]

> One last doubt is that why extended memory not part of the pool.Thanks

Again - you'd have to ask that the developers - and it doesn't make a difference for your problem.

Markus