EXSORT_NOT_ENOUGH_MEMORY

[mahesh_phegade1]

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

[Former Member]

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.