关于ST02看到SWAP红色的讨论

最新推荐文章于 2024-04-19 22:00:00 发布

SAP剑客

最新推荐文章于 2024-04-19 22:00:00 发布

阅读量4.6k

点赞数

分类专栏： SAP Basis

SAP Basis 专栏收录该内容

104 篇文章 37 订阅

订阅专栏

问：在st02中看到，Program和Export/Import的Swap出现红的了，这个是什么原因啊，是不是对系统的性能有影响啊，是否应该调整一些参数啊。要怎么调整呢？
复1：双击红色的部分就可以看到相应的参数修改提示啦～不过曾经有人告诉过我，只要Hitratio的数字是99点多，Swap是红色也没有什么关系，我也不知
道这样的说法是不是正确的，请各位高手指正！

复2：不是很正确：现在看起来Export/import的Buffer设置是偏小了，因为看起来系统启动了6个小时，Export/import的SWAP总数就超过1W了，远高于SAP推荐的警戒值1000/day
建议观察一段时间，如果的确是平均SWAP超过1000/day的话，还是调高一下Export/import buffer比较好。

复3：跟你说这话的人还是有点片面，我不敢苟同这种观点。
我刚做的一个项目，客户情况比较夸张，buffer参数完全没有调整，保持着安装完成的初始状态，整个系统SWAP情况极其严重，特别是Program buffer的SWAP平均超过100,000/day！但你看
Hitratior的话，可能觉得还好，也有97.8%。实际上呢，系统的Free物理内存还有超过600M，这种情况完全属于资源分配不合理；实际运用中他们在执行一些比较大的程序是，速度特别慢：因
为执行的过程中在拼命的SWAP，本来内存里能处理的东西被搞到SWAP里折腾，能不慢吗？
我认为只要有SWAP，你都应进行评估，要尽可能发挥系统最大的潜力。有一家公司的系统我特佩服，<31H的老系统了，用了n多年了（我刚做SAP的时候他们生产系统就已经运行了有1、2年
了），业务量也是巨大的（家用电器生产厂，PP、SD、FI、MM都在用），并发用户也是很多的，可是performance也是不错的，你看人家的SWAP，几乎总是为0（我是一次也没看到过在他们生产系统有SWAP），赞！
再罗嗦一句，Hitratior低也不能代表系统的Buffer没配好，比如说系统刚系统的一段时间里，你会看到Hitratior可能很低，这个很正常，以Program buffer为例：程序系统第一次启动后总归是不在Buffer里的，运行一次后才会在Buffer里，这也就是为什么系统刚启动的时候，SAP用起来好像比平时要慢对Buffer的评价，最好是长期观察、分析，这样的结果更有说服力。

复4：SWAP的单位一律为 “次”。 to:Aming，你们的Export/Import确实小了，10个小时下来都超过7W了，看看物理内存还空吧，如果空可以调一调看。

复5：hehe 这是德式数字你大概用SAP*看的，换个用户，把用户的default里面的数字表现方式改一下。另外关于SWAP的问题要分开来看，如果你只有一台应用服务器（例如CI+DB或者CI&DB），尤其是你们上了多个模块后，各种Buffer会很快的上涨，ABAP尤其如此，而且你会觉得是个无底洞，这是如果要追求好的performance，需要增加DI。另外建议你看看SAP library里关于Memory management的文档，里面描述SAP内存管理的模式，懂了模式才可以掌握如何调整它。

回复:
Good discuss but I still would like to ask Mr. Performance answer this kind of
question. Not because I do not know he need making money from this kind of task. I
do not recommend Jr. basis doing any performance tuning task before you understand
whole system technical architechture.

You should start from following oss note if you have no idea about Performance
optimums via memory mangement. It's really depends on the OS and DB and R3 release.

--------------------------------------------------------------------
OSS NOTE: 103747

Performance in 4.0/4.5/4.6: Parameter recommendations:

Performance in 4.0/4.5/4.6: Parameter recommendations Help

SAP Note Number Note Language DEENJA Display Versions 4950515253
Print SSCR Download

Text Header Data Release Correction Instructions Support Packages >>
Symptom
You want to set R/3 Memory Management. Only an optimum setting of the R/3 Memory
Management ensures error-free operation of the R/3 System and satisfactory system
performance.

After upgrading to R/3 Release 4.0, you notice long response times in the R/3 System.

Last changes:

03/11/1999: New recommendations for abap/heap_area_dia
11/23/1998: Release for customer (ts)
11/13/1998: Additions for AS/400 (rh)
11/17/1998: Revision prior to release for customers (ts)
11/18/1998: AS/400: Implementation of Note 126210 (rh)
01/28/2000: Note 192658: Parameters for SAP BW
02/02/2000: abap/heap_area... and Shared Memory Limit on SINIX
09/03/2000: Released for 4.6A/B
08/28/2000: AS/400: Including recommendations for Rel. 4.6 (rh)
10/26/2000: AS/400: New recommendations for em/initial_size_MB (<=4.5B)
03/06/2001: Shared Memory Management for S/390 Application Server
05/17/2001: Note on em/global_area_MB (-> Note 329021)
11/07/2001: Remove AS/400-specific notes (rh)
02/07/2002: Linux 2.4: Note 386605 for MM

Additional key words
Memory Management, EarlyWatch, GoingLive, Basis course BC315 "Workload Analysis",
Release 4.0

Cause and preconditions
This note is a collection of individual notes on Memory Management for Release 4.0.

The recommendations are intended as initial settings (that is, generally) before or
immediately after a release upgrade. After production start individual parameters
may have to be corrected and the actual requirements adapted.

This note is NOT valid for the IBM iSeries (AS/400) platform. The additional
features of this platform are described in other notes (see item 7 Additional notes).

In Note 192658 you can find additional recommendations for BW Systems.

Solution
***********************************************************************
* Support by TCC Services *
***********************************************************************

In order to ensure good performance after the upgrade, we recommend that you make
use of the TCC services, for example within the Early Watch service contract or
within the Going Live functional upgrade check.

You have to plan for two service sessions, approx. 4-8 weeks before and 2-8 weeks
after the upgrade. The following is required to ensure a good performance:

Before the upgrade:
Plausibility check for the hardware sizing
Recommendations on the configuration after the upgrade
After the upgrade:
Detailed adjustment of the R/3 and database parameters
Identification of unsolved performance problems

Make the dates for the TCC service session in time before the upgrade, in order to
avoid long waiting times for the date !!!

0) What's new in Release 4.0 ?

a) Recommendations for the physical memory:
----------------------------------------

Note 89305 contains information
89305 Resource requirements for Release 4.0A/4.0B
128221 Increased memory consumption with Oracle 8
85524 R/3 scaling (Quicksizer)

The following recommendation for settings apply to application servers with:
>= 750 MByte main memory
> 50 users
> 3 R/3 modules being used

For development and test systems and for very small productive systems smaller
settings may also be possible.

b) Zero Administration Memory Management for Windows NT:
-----------------------------------------------------
In Release 4.0A, the "Zero Administration Memory Management" described in R/3 Note
88416 is active for R/3 under Windows NT. We recommend that you proceed according to
this note for NT. The parameters affected by the "Zero Administration Memory
Management" are marked with (*) in this note. All recommendations in this note for
parameters with (*) therefore only apply to UNIX platforms (except for LINUX, see
below).

c) Standard profiles for UNIX / 4.0B:
----------------------------------
With new 4.0B installations, memory profiles are delivered which depend on the
physical main storage facilities. The parameter "RAM" which the person performing
the installation makes available for the R/3 instance is used as "input". This
results in an "area" according to the following table:

Area │ RAM [MB]
-----------------------------------------------------------------
0 │ up to 750 -> no recommendations given by this note!
I │ 750 <= RAM < 1024
II │ 1024 <= RAM < 2048
III │ 2048 <= RAM -> not for HP-UX and SINIX

Remark: Owing to operating system restrictions, area III cannot be set for SNI/SINIX
and HP-UX with 32-bit kernel.

Parameters are now set depending on the respective area.
The parameters which are set due to the new installation procedure correspond to a
large extent to the recommendations of this note.

With 4.0A installations or upgrades to 4.0, the parameters should be changed
according to this note either before or immediately after the upgrade.

Note 146528 provides extensive information regarding the limitations and options
regarding the configuration of machines with "a lot of RAM" (> 2GByte).

d) Export/import buffer / ATP server:
----------------------------------
An ATP service can be started on an R/3 instance of an R/3 System. This should be
the instance on which the enqueue service is running. In the Default.pfl
rdisp/atp_server = <ATP instance>
(for example, rdisp/atp_server = us0311_ALR_21)
must be set.
If the ATP service is active, Transaction SM51 displays the value "Atp" in the
Service type column. The ATP service stores its data in the export/import buffer.
This buffer on the ATP instance should therefore be configured larger than usual (20
MBytes). (Other programs also use the export/import buffer.)
See also Note 99999.

e) AIX:
----
For large AIX systems (> 1 GByte physical main memory),
refer to Notes 146528, 98084, 95260, 95454, 117267, 124555, and 128935.
CAUTION: Pay attention to the warning in Note 95260 or 117267 !!!

a) Digital Unix:
-------------
Refer to Notes 120539 and 25960.

b) HP-UX and SNI/SINIX (32-bit)
----------------------------
With HP-UX, the allocatable shared memory is limited to approx. 1700 MB for each
server; for SNI/SINIX to approx. 1700 MB for each instance. Therefore, no settings
must be made according to area III for these operating systems. If
em/initial_size_MB and rdisp/ROLL_SHM (in area II) are set greater than the default
values 750 (MB) or 8000 (=64 MB), other shared memory elements (for example,
buffers) must be decreased.

Solution for SINIX: Set up several R/3 instances on one computer or
use the 64-bit R/3 kernel.
Solution for HP-UX: Several R/3 instances are not useful since the
SHM limitation applies per computer. Therefore,
use the 64-bit R/3 kernel.

For the 64-bit kernel also refer to Notes 146528 and 146289.

You can search profiles for errors at the OS level using test program sappfpar
name=<SID> nr= (or sappfpar pf=<full path of profile> (see Note 31395).

c) "Zero Adminstration Memory Management" for Linux:
------------------------------------------------------

With Release 4.5, a simplified memory management has been implemented for R/3 on
Linux 2.4 as well. The following parameters are set automatically: ztta/roll_area,
ztta/roll_first, ztta/roll_extension, rdisp/ROLL_MAXFS, rdisp/PG_MAXFS,
rdisp/ROLL_SHM, rdisp/PG_SHM, em/initial_size_MB. You can also keep parameters
abap/heap_area_dia, abap/heap_area_nondia, abap/heap_area_total on the default
values defined by the SAP System for the time being. We recommend you to proceed as
described in Note 386605.

d) Miscellaneous:
--------------
The changes for the parameters rsdb/ntab/entrycount and rsdb/ntab/ftabsize are
particularly large due to the namespace extension (that is, table name lengths from
10 -> 40 characters). The sizes have more than doubled.
Parameters which are new or are changed significantly as compared to 3.1 are
indicated with "!!!".

1. R/3 buffer

Area-independent:
rsdb/ntab/entrycount 30000 !!!
rsdb/ntab/irbdsize 4000
rsdb/ntab/sntabsize 2500
rsdb/cua/buffersize 5000
sap/bufdir_entries 10000
zcsa/table_buffer_area 50000000
zcsa/db_max_buftab 10000
rtbb/buffer_length 30000
rtbb/max_tables 500

Area-dependent: I II III
rsdb/ntab/ftabsize 20000 30000 30000 !!!
zcsa/presentation_buffer_area 15000000 20000000 20000000
abap/buffersize 240000 240000 400000

Remark on program buffer (abap/buffersize):

A program buffer with 240 MByte is in most cases not sufficient for Release 4.0/4.5.
During production operation it should be enhanced, if required. For this, observe
the "swaps" in the program buffer in transaction ST02. Some 1,000 swaps a day can be
tolerated, but if you find more than 10,000 swaps a day, the buffer should be
enhanced. Note that imports of ABAP programs cause buffer fragmentation and
consequently swaps. To avoid this, reduce the number of transports in your
production system!

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

Windows NT: PXA_NO_SHARED_MEMORY because of address space fragmentation. Defective
basis addresses of NT system DLLs fragment the address space of work processes. The
large related Shared Memory Segments (PXA, Extended Memory, ...) possibly cannot be
created, because the available free address space is being fragmented by these DLLs.
This leads to a start with the NOT-PXA buffer of 4 MB. As a workaround the parameter
em/address_space_MB can be reduced to 250 MByte (also refer to the internal Note
129813).

AIX: Note 98084 "AIX: ABAP programm buffer PXA larger than 256MB"

HP-UX and SNI: Because of the Shared Memory restrictions (see above), an enhancement
of the program buffer can lead to error PXA_NO_SHARED_MEMORY. In this case other
Shared Memory Segments have to be made smaller.

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.)

The buffer sizes specified are standard installation values. After the production
startup, you have to adjust the parameters to the actual requirements. To do this,
call Transaction ST02. If displacements occur in column "Swaps" you should increase
the buffers in question (however, note that up to 10,000 swaps may occur in the
program buffer).

Export/import buffer:

The settings recommendations for the export/import buffer are area-independent and
depend on the application programs you use. As standard settings we recommend:

Release 4.0/4.5:
rsdb/obj/buffersize 4096 (KB) !!!
rsdb/obj/max_objects 5000 (buffer entries) !!!
rsdb/obj/large_object_size 8192 (bytes) !!!

As of Release 4.6:
rsdb/obj/buffersize 20000 (KB) !!!
rsdb/obj/max_objects 20000 !!!
rsdb/obj/large_object_size 8192 (bytes) !!!

If the export/import buffer is swapped a lot (more than 1000 swaps/day) then it
should be enlarged.

2. Local memory for work processes (roll memory)

***********************************************************************
******** Parameters with (*) only apply to UNIX. ***********
******** For NT see Note 88416. ***********
******** For Unix see Note 386605. ***********
***********************************************************************

ztta/roll_area (*) 6500000

ztta/roll_first (*) 1

3. Roll buffer and extended memory (except Windows NT)

Area-independent:
ztta/roll_extension(*) 500000000 !!!
AIX: 2000000000

(Note: When using the alternative Memory Management on AIX (see Notes 95454 and
124555), ztta/roll_extension must be set as is recommended in these notes.)
rdisp/ROLL_MAXFS (*) optimal: 32000, minimal: 16000
rdisp/PG_MAXFS (*) optimal: 32000, minimal: 16000
rdisp/ROLL_SHM(*) 8000 (up to 16000) !!!
rdisp/PG_SHM(*) 1000
em/global_area_MB for SAP kernel < 4.6D: 24 (default)
for SAP kernel >= 4.6D:
10% of em/initial_size_MB, maximum
(see also Note 329021) 255 - em/blocksize_KB / 1024 (AIX)
10% of em/address_space_MB (Windows)
255 (others)

Area-dependent: I II III
em/initial_size_MB(*) 512 750 (to 1000) 1000 (to 2000)

The specified values em/initial_size_MB and rdisp/ROLL_SHM are the standard
installation values. After production startup, you must adjust the parameters to the
actual requirements. To do this, call Transaction ST02. If the line "Extended
Memory" contains
"In memory" - "max. use" < 20% of "In memory"

you should enlarge the em/initial_size_MB (within the scope of the values entered in
parentheses above).

In other words: 20% extended memory should also be free at times of high load.

If the line "Roll area" contains
"Max. use" > "In memory"
you should increase rdisp/ROLL_SHM (within the above-mentioned values specified in
parentheses).

4. Heap memory (except Windows NT)

abap/heap_area_dia and abap/heap_area_nondia (new as of 03/11/1999):
In general, we recommend setting
abap/heap_area_dia(*) = abap/heap_area_nondia(*)
as follows:

AIX:

Standard: 180000000 (180 MByte)
If ES/TABLE = SHM_SEGS is used (Notes 95454 & 124555)
80000000 ( 80 MByte)

HP-UX:

up to HP-UX Releases smaller than 10.20:
600000000 with OS parameter: maxdsize = 640 MByte
as of HP-UX Release 10.20, the following size is possible:
920000000 with OS parameter: maxdsize = 944 MByte

SNI (SINIX): 350000000

Note: Value 350000000 for abap/heap_area(non)dia is a standard value
which can be used for almost all SINIX/Reliant systems. In rare cases however,
memory management errors can occur. In this case you may be able to solve the
problem by reducing the parameter further (for example, 250000000).

DEC: 900000000

Sun: Standard: 900000000 (900 MByte)

Caution: If you set em/initial_size_MB > 1500, you must reduce

abap/heap_area_dia and abap/heap_area_nondia (see also

section 8f) in Note 97497).

Windows: Delete the profile paramter from the profile

abap/heaplimit(*) 20000000

Area-dependent: I II III

abap/heap_area_total (*) 750000000 750000000 1500000000

5. Basic information on the parameter settings
You must save your old profiles before the change. If the instance with the new
parameters does not start, you can use the old profile.
All parameter settings must be checked before being used (program sappfpar, in the
test system and so on).
Consider the architecture restrictions of the operating systems (for example, Shared
Memory restrictions). If you do not consider these restrictions errors and
terminations may be the result.
Consider that actual recommendations on the parameter settings by the TCC can only
be provided within the service sessions.

***********************************************************************

WARNING:
If the R/3 memory areas are set up too small (R/3 buffers, R/3 Extended Memory, and
so on), unnecessary performance problems may occur. If the memory areas are set up
too large, errors can occur when you start the R/3 instance, or runtime errors may
occur. The optimum settings are dependent on the hadware (CPU and RAM), the R/3
release and the operating system release. The TCC Services GoingLive and EarlyWatch
will provide you with individual recommendations for your system.

***********************************************************************

6. Miscellaneous

Also see the sections "Swap Space", "File System Cache", "Dependencies of the
operating systems", and "Questions and answers" in Note 97497.

7. Additional notes:

Notes for IBM AS/400
139326 AS/400: Memory Management in Release as of 4.6A
126210 AS/400: nametab buffer larger than 16MB
123418 AS/400: Performance 4.0B on AS/400
121625 AS/400: buffer size
119754 AS/400: Parameter for nametab buffer
110157 AS/400: Generic table buffer
79478 AS/400: ERROR => ShmCreate (...)
73628 AS/400: MCH3601 in rstsac2/convert_ABAP_to_C/9
44695 Memory Management in Release as of 3.0C, AS/400

Notes on IBM S/390
326949 Shared Memory Management S/390 Application Server

8. Questions and answers

(See also "Questions and answers" in Notes 33576 and 44695 and
the SAP TechNet article "Memory management as of Release 3.0C"
(http://sapnet.sap-ag.de/TechNet -> System Monitoring
-> Knowledge Base -> New Memory Management.)

For background knowledge on memory management of R/3 you can also
refer to the book "R/3 Performance Optimization"
(ISBN 0-7821-2563-8)

a) Why is em/initial_size_MB in area III (RAM > 2000 MByte) set to 2000 MByte in so
restrictive a manner?

The main reason is that the 32-bit architecture available to us at present can
manage an address space of a maximum of 2GB - 3.8GB (depending on the operating
system). For category III, the address space is made up as follows:
em 1024MB (shared)
PXA 400MB (shared)
Roll 64MB (shared)
sonst. 150MB (shared)
heap 1500MB (local)
stack 50MB (local)
..........
3138MB

b) Which parameters should be changed for prevention ?

Parameters ztta/roll_extension, rdisp/roll_MAXFS, abap/heap_area_(non)dia,
ABAP/heap_area_total, and rdisp/pg_MAXFS do not influence the performance (in the
sense of "velocity"). They are only "stability-relevant", that is, they prevent
programs from terminating. These parameters should therefore be changed for
prevention.
Example:
Even if the system "never" needs 256 MB of paging (rdisp/pg_MAXFS = 32000), you
should not economize on the paging file. It is senseless to wait until the year-end
settlement terminates since the paging area was configured too small and only
afterwards is the paging area to be configured "on request".
Similar examples apply to the other parameters.

As opposed to this, the buffer sizes (abap/buffer_size ... ) only influence the
response time. In the case of emergency you can wait until the buffer starts to swap
and then raise the response time. (However, you can also set it "large enough"
immediately).

Source code corrections

回复6：

to: Ben & newcat  好久没来, 谢谢两位还记得我
to:aming&schwalbe
你们的系统export/import的参数设置的确是有些问题. 但并不是你export/import的buffer大小不够,而是你系统中为export/import预留的最大object数值不够大.
系统当前的object数为2000个且已经被用完了,所以尽管还有82.07%和22.91%的export/import空间却不能够被利用.
rsdb/obj/max_objects   =2000 改到  5000
rsdb/obj/buffersize  = 4096 改到  8192 ( for schwalbe)
情况会有改善的.
schwalbe 你的program buffer size 有点小了,我不知道你的软硬件具体情况所以不好给出具体的数字.
如果是32位R/3跑在unix系统下的话尤其要小心,仔细调整pool 10和40的值,不然系统很可能起不来.
我个人认为没有必要一定要刻意追求所有的SWAP一直是0.