Page tree
Skip to end of metadata
Go to start of metadata
  • Purpose

The purpose of this page is to clarify the understanding of PXA and Load inconsistencies.


  • Introduction

The ABAP Program Buffer (aka PXA = Program eXecution Area) is a Shared Memory segment which is used for storing program loads and other objects used by the ABAP VM.
It exists once per application server starts and is shared among the work processes
  • Parameter

abap/buffersize =  size of the PXA shared memory  [kB]

abap/pxa_cache = no. entries in the PXA cache (0 disables the cache, min = 1024, max = 16384, default depends on size of PXA)

abap/pxa_preload = max. percentage of the buffer space to be filled by the preload (default = 20), see note 1122370.

abap/buffer_fragments = no. of PXA fragments (valid: 1-16), default calculation has recently been changed, minimum fragment size: 7.20: 300000, 7.21: 500000.


  • Preload configuration

The preload is configured by / operates on the following files in the work directory:


Each of those files contains a list of ABAP programs (one per line) in the following format:

x <technical program name>




x CL_HTTP_SERVER================CP

Please also check 23642 - Description of pxanew and pxastat


Preload Processes during System Startup and Shutdown

Startup phase:

-the first process to acquire the PXA semaphore (key #1) will create the PXA
-all other processes will attach themselves to the PXA
-work process #1 will begin preloading objects into the PXA
Ÿ  -starting with pxauserload
Ÿ  -then using pxanew
Ÿ  -then using pxastat
Ÿ  -finally renaming pxanew to pxastat (thereby deleting the old pxastat)
-when the buffer is filled up to the percentage specified in abap/pxa_preload the preload is stopped

Shutdown phase:

-work process #1 will save most frequently used programs to pxanew
  • PXA Runtime Errors

  • Inconsistencies

    -PXA_DESTROYED (happens rarely)

Ÿ       -is signalled for inconsistencies like directory overflow (should no longer occur with up-to-date kernel), failing consistency check, LRU chain defect, memory chain defect
Ÿ       -Reload request is sent to all processes and PXA is reinitialized after 20 seconds. Might lead to core dumps for processes continuing after more than 20 seconds

       Solution: Normally errors don’t come up again after re-initialization. 

    -PXA_HASH_LOOP (happens very rarely)

Ÿ       -endless loop in hash chain; might happen in case of overwritten PXA

        Solution: Assure protection is set (abap/pxa=..,protect)


  • Overwritten memory

    If there are short dumps which could not be explained like

    •CALL_FUNCTION_NOT_FOUND (with an invalid function module name)

    it is very likely that program buffer memory has been overwritten.

    Solution: Assure that the PXA protection is active and restart the server.

    Relevant  notes:

      Note 305940 - Memory overwriters in program buffer

      Note 951439 - PXA-Buffer protection on HP-UX systems

      Note 1639598 - Memory protection on program buffer

      Note 1764470 - Memory protection for program buffer on AIX


  • Storage shortage

     -PXA_NO_SHARED_MEMORY (happens rarely)

Ÿ        -there is not enough shared memory to allocate the program buffer. Usually occurs on 32 bit platforms
Ÿ        -system switches to emergency mode (32MB); only WP0 and WP1 come up
Ÿ        -WINDOWS NT: lack in page file (note 1790345), address space fragmentation (note129813)

        Solution: Reduce size of program buffer and restart

      -PXA_NO_FREE_SPACE (happens more frequently)

Ÿ         -there is not enough space to allocate the mentioned program

          Analysis:  check sizes of program and fragment and number of fragments

          Solution: Decrease number of fragments (profile parameter abap/pxa_fragment). If whole PXA too small increase its size 








  • No labels