Application buffer swaps and HP-UX swaps

[Former Member]

Hello all,

I would like to consult with you regarding our production instance swaps on OS and on application level.

On application level, in transaction ST02:

1.GENERIC KEY BUFFER has around 300 swaps per week:

zcsa/table_buffer_area 60000000 Byte Size of generic key table buffer

zcsa/db_max_buftab 10000 Max. number of buffered objects

2.Program buffer has more than 15000 swaps perday: PXA

abap/buffersize 500000 kB Size of program buffer

abap/pxa shared Program buffer mode

3.Export/import (sometimes to 230000 swaps):

rsdb/obj/buffersize 20000 kB Size of export/import buffer

rsdb/obj/max_objects 20000 Max. number of objects in the buffer

rsdb/obj/large_object_size 16384 Byte Estimation for the size of the largest object

What is your opinion, should we increase the buffers sizes?

How much should be the abap/buffersize, regarding the fact that we have two production SAP instances on the same HP server?

Should we put for parameter ipc/shm_psize_06 = -10, segment 06 to be included in pool 10, currently ipc/shm_psize_10=24000000?

Should also the parameter ipc/shm_psize_02 = -10?

In note 37537:

“It is especially important that R/3 shared memories with numbers (keys) 02 and 06 are in the same shared memory pool.”

In note 103747:

“The enhancement of program buffers (abap/buffersize) can cause problems in the memory administration”

“With HP-UX you have to consider the following:

If the total out of program buffer and EM is higher than 1000 MB, the program buffer has to be in a pool:

if abap/buffersize + em/initial_size_MB > 1000 MB.

ipc/shm_psize_06 = -10 and

ipc/shm_psize_02 = -10

(This measure is necessary to avoid a Shared Memory fragmentation.)”

On HP-UX level:

hostname : sap_serv

model : 9000/800/N4000-55 (server)

CPU : (8) PA8600 550 MHz (PA-RISC 2.0)

RAM : 8 GB

OS : HP-UX B.11.00 (64-bit)

JVM : Java 1.3.1.12 (/opt/java1.3/bin/java)

The latest OS patches from March 2004 for HP-UX 11.00 are applied on the system.

sap_serv:/#swapinfo -tam

Mb Mb Mb PCT START/ Mb

TYPE AVAIL USED FREE USED LIMIT RESERVE PRI NAME

dev 1536 0 1536 0% 0 - 1 /dev/vg00/lvol2

dev 20480 3563 16917 17% 0 - 0 /dev/vg00/lvswap2

reserve - 12455 -12455

memory 6217 668 5549 11%

total 28233 16686 11547 59% - 0 -

sap_serv:/#vmstat -S 5 5

procs memory page faults cpu

r b w avm free si so pi po fr de sr in sy cs us sy id

0 3 0 337169 7541 16728 16799 4 6 24 0 77 2917 4434 408 3 1 96

0 2 0 352031 7475 5 5 14 22 1 0 15 2675 4544 399 3 1 96

0 3 0 378783 7795 5 5 4 83 9 0 67 2662 7508 474 7 2 91

3 1 0 729871 8079 5 5 56 108 60 0 119 2733 15677 1002 9 3 88

2 2 0 719061 8007 5 5 36 34 28 0 38 2669 10557 741 9 2 90

sap_serv:/#

What do you think how to decrease swapping on our server?

Do you have some suggestions?

We have users complains regarding the SAP application performance. We need to determine the reason if it is connected with the swapping problems.

Thank You in advance.

Best Regards,

Ruzica Kalkasliev

[Former Member]

Hello Ruzica,

When running sappfpar, are you definitely using the currently used instance profile? (Example sappfpar check pf=/usr/sap/P01/SYS/profile/P01_DVEBMGS00_uedcb013). If run against the used profile there should be a section in returned result like following: "Checking profile: /usr/sap/P01/SYS/profile/P01_DVEBMGS00_uedcb013". When sappfpar is ran against the used instance profile then there should always be a match between values in the instance profile and recommendations given.

There should be no tecnical issues with increasing the buffers outside of the pool 10 also, I would suggest you test this on Dev or Test system first if unsure about impact. Later you can move to pool 10 and check if performance is improved slightly but the main thing is to reduce the swaps in ST02 at this stage. The transaction AL13 should allow you to calculate the total size needed for each pool 10 and 40 also.

Note #146289 (Parameter Recommendations for 64-Bit

SAP Kernel) including the section:

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

2. There are no restriction of shared memory, so all buffers sizes

can be set very generously (see recommendations for category III

in SAP note 103747).

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

The SAP Help Portal contains more related general information about moving keys in and out of pools also at:

http://help.sap.com/saphelp_webas620/helpdata/en/c4/3a6f41505211d189550000e829fbbd/frameset.htm

Lastly, the notes such as #523505, #545422 and #497427 discuss how for every host where a SAP J2EE Engine will run that setting should be 'ipc/shm_psize_02=0'. In this case ipc/shm_psize_06 should also remain outside of pool 10.

Regards, Mark

[Former Member]

Hello Mark,

Thanks for all your explanation I will really use it.

Many regards,

Ruzica

[Former Member]

Hello Ruzica,

One thing I forgot to mention, as shared memories and buffers become bigger, at the same time CPUs become faster while pools are still restricted to 2GB because

of compatibility reasons (note #669550 has more information). The performance benefits for keeping buffers in the pools become less important as CPUs get faster but key 6 and 2 should still remain in the same pool or outside of the pools.

With the size of the pools you mention above, this 2GB limit shouldn't be an issue.

Regards, Mark

[Former Member]

Hello Mark,

Thanks for the information.

This weekend I will change the program buffer and export/import buffer on the test instance and if works fine change the production buffers.

Many regards,

Ruzica

[Former Member]

Hello Ruzica,

For best performance you should aim for no swaps in ST02 buffers except for the PXA (Program) buffer where up to 10,000 swaps per day can be tolerated. You should increase zcsa/table_buffer_area in small increments of about 5% so that there are no swaps.

Parameter rsdb/obj/buffersize may need to be doubled if so many swaps as a first step for optimistion. You may need to increase the program buffer in 50MB steps until swaps are less than 10,000 per day. It may take a couple of restarts until parameters are right for the best instance performance.

Note #103747 restrictions are mostly for 32-bit systems and there such limits for 64-bit systems for address space so having two instances on the same server will not influence recommendations for increasing the SAP buffers sizes but you should review note #37537 (Improved performance with shared memory pools). You should move ipc/shm_psize_06 and ipc/shm_psize_02 into pool 10 and then check sappfpar to ensure that ipc/shm_psize_10 is sized large enough for the above increases.

I hope this information helps you in optimizing the SAP buffers section of your query about improving performance on the system.

Regards, Mark

[Former Member]

Hello Mark,

I've started the sappfpar and something is wrong

***ERROR: Size of shared memory pool 10 too small

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

SOLUTIONS: (1) Locate shared memory segments outside of pool 10

with parameters like: ipc/shm_psize_<key> =0

SOLUTION: Increase size of shared memory pool 10

with parameter: ipc/shm_psize_10 =30000000

***ERROR: Size of shared memory pool 40 too small

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

SOLUTIONS: (1) Locate shared memory segments outside of pool 40

with parameters like: ipc/shm_psize_<key> =0

SOLUTION: Increase size of shared memory pool 40

with parameter: ipc/shm_psize_40 =68000000

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

In the instance profile ipc/shm_psize_10 = 24000000 and ipc/shm_psize_40 =116000000, why sappfpar says to increase the segment to 68000000.

I've tested on test instance that is homogenous system copy from the production, I changed the ipc/shm_psize_10 as sappfpar says, restart the instance and tried the sappfpar again. It says the same errors.

About the program buffer, I'm not sure, if I change it like you said, first with 50MB step, must I move ipc/shm_psize_06 and ipc/shm_psize_02 into pool 10?

I've never tuned any of this parameters, this should be done on production and I'm a little bit careful.

Thanks in advance,

Regards,

Ruzica