on 12-05-2008 2:09 PM
Dear All,
We are getting this dump while blocking PO in ME32L in our production.
Production is on Windows NT 32Bit with 4 GB physical RAM.
Standard parameter--
ztta/roll_first 1
ztta/roll_area 2000000
ztta/roll_extension 2000000000
ztta/max_memreq_MB 1048
em/address_space_MB 512
em/initial_size_MB 4092
em/max_size_MB 20000
em/global_area_MB 128
em/stat_log_size_MB 20
em/stat_log_timeout 0
ztta/roll_area 2000000
abap/heap_area_dia 2000000000
abap/heap_area_nondia 2000000000
abap/heap_area_total 2000000000
rdisp/ROLL_SHM 32768
rdisp/PG_SHM 16384
rdisp/PG_MAXFS 32768
abap/buffersize 400000
abap/heap_area_dia 2000000000
abap/heap_area_nondia 2000000000
abap/heap_area_total 2000000000
abap/heaplimit 40000000
Please suggest
Regards,
Mahesh
Hello,
The reasons for the dump are described in SAP note #193529 (Sort as of 4.5A /
EXSORT_NOT_ENOUGH_MEMORY) I will also outline some other steps:
Possible solutions:
1. Normally reducing parameter abap/heap_area_nondia is sufficient
to provide HEAP memory for example a SORT operation. So you can
reduce the parameter slightly, and then check the problem
again. For more info, please refer to note #193529. Suggest
to leave this option until last if it's a Windows 32-bit instance.
2. You can consider reducing the shared memory areas such as the
program, roll or paging buffers. If necessary investigate
the potential for this on the instance where the dumps occur
if the information below is not clear enough to determine if
roll and paging buffers can be reduced from defaults.
3. Activate the '/3GB' option, please refer to note #313347 to check
if your edition supports this being set in the C:\boot.ini file.
http://support.microsoft.com/kb/28303, has more information about
the /3GB option.
These errors can be due to lack of address space or that
the data selection is too large for the available memory of the
instance and needs to be reduced to ensure that it can finish without
memory terminations.
More information about this topic that can be applied to any
Windows 32-bit instance:
====================================================
To re-allocate some of the unused shared memory to program memory,
a prime candidate for this is Roll and Page "In Memory" values.
Alternative memory management via PHYSMEMSIZE generally overallocates
roll and page memory. Please reduce the amounts allocated to the "in
memory" part (see ST02) using the parameters below...
Zero administration memory management (Note #88416) generally
overallocates roll and page memory. Usually you can reduce the
the amounts allocated to the "in memory"
rdisp/ROLL_MAXFS....Total amt of ROLL (Filesystem+SHM); in 8KB blocks
rdisp/ROLL_SHM......Shared memory element of Roll; in 8KB blocks
rdisp/PG_MAXFS......Total amt of Page (Filesystem+SHM); in 8KB blocks
rdisp/PG_SHM........Shared memory element of Roll; in 8KB blocks
=>Filesystem amount. = MAXFS - SHM
Bear in mind that Roll_SHM MUST be greater than 10% of Roll_MAXFS.
60MB or so each in memory should be sufficient. rdisp/ROLL_SHM &
rdisp/PG_SHM only to be changed. This should allow extra
memory for process memory.
It also important that after changing the parameters that you
monitor in TA ST02 the consumption of Roll and Paging in the system.
If the value of 'Max. use' for the Roll-Area reach the value
'In memory' then you should increase the parameter rdisp/ROLL_SHM
to e.g. 10000.
Example:
rdisp/ROLL_SHM changed from 32768 to 7500 (60000/8) to change
the 'in memory' Roll area from 262,144 kB to 60,000 kB
====================================================
An increase in available address space by reducing buffers as above or
more importantly the PAE /3GB flag if possible may be enough to ensure the
successful completion.
Regards.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
101 | |
13 | |
13 | |
11 | |
11 | |
7 | |
6 | |
5 | |
4 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.