Tuesday, December 15, 2009

Swap Space Bottleneck During SAP Operation

 
Symptom

Diverse error messages that refer to memory bottlenecks, or, more precisely, a swap space bottleneck. For example, System Panic; cmemreserve: reservation overrun; ENOMEM, Not enough core; ENOSPC, No space left on device; SIGDANGER (under AIX only). In the SAP System, the SAP system log message "no memory of class perm" is output.

This problem can occur with SAP processes and external processes as well. The relevant process cannot allocate anymore heap memory. This can lead to the database operation being ended or SAP work processes being stopped.

Error messages in the SAP System appear in the developer trace files

dev_disp, dev_w<n> in the system log and in dumps. The following messages may appear: TSV_TNEW_;._NO_ROLL_MEMORY; NO_MEM; NO_MEMORY; RESIZE_EM_ALLOC_ERROR, Storage class PERM.

This problem mostly occurs if background jobs are active with large amounts of data.

Possible Causes

  • There is no more swap space available
  • The highest value for one of the SAP profile parameters that limit the swap space usage has been exceeded. In this case, the following parameters are relevant:
  • abap/heap_area_dia, abap/heap_area_nondia and abap/heap_area_total.
  • The operating system limits for the process size (segment size) have been exceeded. For example, no more that 256 MB can be assigned under AIX and no more than 384 under SINIX.
  • Corrective action

    Increase the swap space or decrease the

    SAP Extended Memory. If the swap space already corresponds to the SAP recommendations, 1.5 to 2 GB may still be required. There should always be several hundred MB of free swap space available. You can reduce the maximum swap space need of the SAP System by reducing the value of parameter abap_heap_area_total.

    You can also distribute the load onto several application servers and increase the roll area. Check if the maximum process size (operating system parameters) is sufficient.

     

    The rsmemory Report

     
     You can use the rsmemory report to define your memory allocation strategy for work processes. You can specify the memory class assigned to a work process, the extent of the class assigned, and the order in which it is allocated. A distinction is made here between dialog work processes and non-dialog work processes (batch, update, spool).

    Changes made here only apply to the server on which you are currently logged on and only remain in effect until the SAP instance is stopped again.

     The following memory classes exist: SAP roll area, SAP Extended Memory, and private memory. These memory classes are assigned the following values, which are also displayed in the initial screen of the rsmemory report.

    Value

    Memory class

    0

    Roll area

    1

    Extended Memory (EM)

    2

    Private memory (heap)

    The initial screen of the report comprises three parts:

    • Quota Dialog:
    • The allocation strategy for dialog work processes is defined here. You can specify the steps in which each class is allocated memory, and how much memory is allocated.

    No entry in the memory class field corresponds to class 0 (heap memory).

    The entry here does not have to match the defined memory parameters. If you enter a value for the heap memory in the 4th step that is different from the abap/heaparea_dia parameter, the value entered here takes precedence.

    In this case, 1 MB of roll area is first allocated by a dialog work process, and then 300 MB of extended memory. Following this, 6.5 MB of roll area are allocated again before 200 MB of heap memory (the process then switches to PRIV mode) are allocated.

    • Quota Batch/VB/Spool:
    • As is the case with the quota dialog, the allocation strategy for non-dialog work processes is defined here.
  • Other parameters: You can change the following memory parameters here for test purposes (these changes only apply until the next server restart):
    abap/heap_area_dia
  • abap/heap_area_nondia
  • abap/heap_area_total
  • em/stat_log_timeout
  • em/stat_log_size_MB
  • em/global_area_MB

     Displaying the Memory Areas:

    You can display a list of all the users on the application server, with their respective memory requirements, by choosing Goto ® EM/HEAP areas. The used heap memory and extended of the user are displayed first, followed by the EM usage according to internal sessions.

    This is followed by a history of users who have used more than the MB limit specified by em/stat_log_size_MB.

    The available HEAP and EM memory is displayed at the end of the list.

    EG Overview

    The buttons EG Overview and EG Dump are used to analyze the Extended Global Memory. This is a part of the extended memory that is available for SAP-internal purposes. The parameter

    em/global_area_MB sets the size of Extended Global Memory.

    Activities

    In the initial screen of transaction
    se38, enter the report rsmemory and choose Execute or F8.
     

    Checking Roll /Paging Area and Extended Memory with Tcode ST02

     

    In the entry screen of transaction ST02, there is an overview of SAP Memory under the Buffer overview.

    SAP memory

    Current use

    Max. use

    In memory

    On disk

    [%]

    [kb]

    [kb]

    [kb]

    [kb]

    Roll area

    5.47

    448

    1,280

    8,192

    0

    Paging area

    0.01

    16

    72

    9,600

    252,544

    Extended Memory

    4.03

    6,144

    22,528

    152,576

    0

    Heap Memory

    0

    0

    0

    0

    0

    This is a snapshot of the current (percentage and absolute values in kilobytes) and the maximum memory usage of the various

    SAP memory types. The table also indicates whether, and to what extent, the requirement is satisfied from the main memory and from the disk.

    You can determine from the row

    Extended Memory that the SAP Extended Memory is sufficiently large. The value [Max. use] is, in this example, noticeably smaller than the created memory area [In memory]. If both values are identical, you must increase the extended memory (profile parameter: em/initial_size_MB).

     

    Virtual Address Space of a Work Process




    With 32-bit systems, 4 GB of memory can theoretically be addressed; depending on the operating system, there are approximately 2 GB of virtual address space available to a process.
    This consists of a text and a data segment, a dynamically extendible heap and a dynamically extendible stack. The heap increases in size from the bottom and the stack increases from the top; this enables the entire virtual address space to be used.

    With an SAP work process, there are special areas reserved on the heap whose size can be set using a profile parameter. These are:

    Roll area
    SAP paging area
    Private memory

    The largest reserved area is located between the heap and stack: of the SAP Extended Memory.

    SAP Memory Types : Private Memory

     
     Other processes cannot use private (heap) memory. After releasing the assigned memory, the operating system still considers the (virtual) memory as being occupied by the allocating process. These characteristics of heap memory require that:
    1. The work process can be run in PRIV mode (private) when the local memory is assigned. This means that the work process is reserved for processing the current user context until the context releases the work process again when the request has ended.
    2. The work process, if it has used a lot of private memory, is restarted when the user context is terminated and the local memory is returned. The restart makes the local memory available again for other processes. A restart occurs if a work process uses more local memory than is defined in the parameter abap/heaplimit. The mechanism is displayed again there.
     
     If a dialog work process has used up the roll area assigned to it and the extended memory, private memory is assigned to the work process. The work process goes into PRIV mode (private).

    In the parameter settings, ensure that not too many dialog work processes are simultaneously in the PRIV mode, since this lowers system performance.

    The other Work Process types (background, update, enqueue and spool work processes) are assigned heap memory after the roll area is used up. Allocating Extended Memory is not useful since no context change occurs for these processes.

    Automatic Termination of PRIV Mode Processes

    If too many dialog work processes run in the PRIV mode in an SAP application server, performance problems arise. The normal processing of user inquiries is slowed down by the PRIV mode work processes.

    The SAP System offers a mechanism that lets you terminate non-active dialog processes in the PRIV mode. This mechanism helps reduce performance problems.

    The mechanism works as follows:

    In the PRIV mode, a maximum number (n) of dialog work processes can run without any time restrictions.

    To determine this number n, set the value of the profile parameter

    rdisp/wppriv_max_no
    . If a value is not entered, the SAP System determines this number using the following formula:

    the number (n) is set to the greater of the 2 following values:

    • Number of dialog work processes minus 5
    • 1

    If more than (n) dialog work processes are active and the time span set in parameter

    rdisp/max_priv_time (default 600 seconds) has elapsed, the transaction for that PRIV process, which has spent the longest possible time in PRIV mode, is reset.

     

    SAP Memory Types :: Extended Memory

     
    SAP extended memory is the core of the SAP memory management system. Each SAP work process has a part reserved in its virtual address space for extended memory. You can set the size of extended memory using the profile parameter em/initial_size_MB: Extended Memory Pool Size. Under Windows NT, further memory is assigned dynamically as needed, and you can also set this amount.
     

    You can map the extended memory from the common resource onto any work process, and after onto another process (see graphic) on the same address in the virtual address space. This is important if you work with pointers in the ABAP program.

    Depending on the operating system, how you implement the extended memory is different.
     
    The SAP system builds a layer on to the operating system functions for the page management of this memory. This extended memory is implemented as an unnamed mapped file. This means the address space uses the paging file or uses the swap space of the operating system as background memory.
     

    SAP Memory Types :: Roll Area

     

    The roll area is a memory area with a set (configurable) size that belongs to a work process. It is located in the heap of the virtual address space of the work process.

    iSeries:

    the roll area is a fixed-size (configurable) area of memory situated in the shared memory in the virtual address space of the work processes.

    When the context of a work process changes, the data is copied from the roll area to a common resource called the roll file. To prevent repeated copying, another roll buffer is located in between that is part of the shared memory.

    iSeries:

    if the context changes, quick mapping operations are performed that make the current shared memory segment in the work process available.
    The roll area consists of 2 segments. The first segment, which can be set with the parameter ztta/roll_first, is assigned to the work process first as memory. If this is used up, the work process has more memory assigned to it. The amount of memory is determined by the difference between the parameters ztta/roll_area  and ztta/roll_first.
     

    SAP Memory Types

     
    The memory management system assigns memory to a work process. Here are some of the various memory types:
     
    SAP Roll Area
    SAP Extended Memory
    Private Memory
     

    The roll area is used for the initial memory assigned to a user context, and (if available) for additional memory if the expanded memory is full.

    The majority of the user context is stored in the extended memory. Page management of this memory as a stack is not taken from the operating system; rather it is performed directly from the SAP System. This extended memory is implemented as an unnamed mapped file (on AIX and optionally on HP-UX as shared memory). This means the address space uses the paging file or uses the swap space of the operating system as background memory. For more information, please see the platform-specific documentation.

    With the context change, the user context is not copied as with the roll area. Instead it is assigned to alternating work processes by mapping operations. The roll area can be decreased, which results in a faster context change because less data is copied and mapping an extended area is not work-intensive.

    All internal tables and ABAP variables are located completely in the area of a user context that can be directly addressed. Copying and in/output operations when accessing internal tables and lists is no longer needed. The result is low CPU usage and shorter access times.

    The advantages of the memory management system require increased swap space and main memory. The need for swap space increases because full-sized internal tables and lists are in the address space and take up swap space. The main memory requirements may increase to prevent excessive operating system paging due to the increased swap space requirements.