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:
pxauserload
pxanew
pxastat
Each of those files contains a list of ABAP programs (one per line) in the following format:
x <technical program name>
Examples:
x IF_AUNIT_ATTRIBUTE_ENUMS======IP
x SAPMSSYD
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
•SYSTEM_RUDI_INVALID•RUNT_ILLEGAL_SWITCH•RUNT_INTERNAL_ERROR•CALL_FUNCTION_NOT_FOUND (with an invalid function module name)•SYSTEM_CORE_DUMPED•PXA_DESTROYEDit 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