The runtime error PXA_NO_FREE_SPACE occurs(displayed, for example, in transaction ST22).
Almost always, one of the two following cases is the cause for runtime error PXA_NO_FREE_SPACE:
1. The following situation occurs as of Release 6.10:
The program buffer consists of several fragments, which are relatively small (300 to 400 MB). The smaller a fragment, the higher the probability that a PXA_NO_FREE_SPACE short dump occurs. You can use the undocumented profile parameter abap/buffer_fragments to reduce the number of fragments.
2. You have selected the program buffer too small (parameter abap/buffersize).
doc that a separate program buffer exists for each application server. Consequently, another setting of the parameter abap/buffersize can also be selected for each application server.
3. Due to missing shared memory, the program buffer cannot be created in the size entered in the parameter abap/buffersize.
It is created in the emergency mode with a smaller size. The size of the program buffer is either 4 MB for each work process or 32 MB in the shared memory, depending on the release level or patch level of the kernel. The size of the program buffer is also mentioned in the runtime error text under "Description of the error scenario") Apart from PXA_NO_FREE_SPACE, runtime error PXA_NO_SHARED_MEMORY is also often found. This error appears in the status bar as a message when you are booting, or as a short dump during the login.
In exceptional cases, the runtime error PXA_NO_FREE_SPACE may have another cause. The following list contains all known cases:
4. The following situation only occurs up to and including R/3 Release 4.0B:
The runtime error PXA_NO_FREE_SPACE occurs because many objects in the program buffer are locked by invalid LOCK counter values and thus cannot be displaced. You can check this situation in the ABAP debugger as follows:
Switch to the display of the system area (Goto -> System -> System Areas) and enter 'PXA' as the area name. The system will display a list of all objects in the program buffer. Objects that cannot be displaced contain a value not equal to zero in the column 'LOCKS'. Valid values in this column are 1, 100, F0F, 1000, 10000 and combinations or multiples of these values, for example: 20001. Since the LOCK counter in the shared memory is modified without semaphore protection for performance reasons, the system may generate invalid values in exceptional situations, as a result the objects remain locked until you shut down the application server. This error situation increasingly occurs on multiprocessor machines having many processors.
5. The following situation only occurs up to and including R/3 Release 4.0B:
The short dump PXA_NO_FREE_SPACE occurs several times although a high percentage of the program buffer is free according to transaction ST02. In addition, the portion of the gaps is almost as large as the portion of the free buffer.
6. The following situation only occurs up to and including R/3 Release 4.0B:
Transaction ST02 displays swaps for the program buffer (PXA) although sufficient space is free in the buffer. In addition, doc that an enlargement of the program buffer does not significantly improve the swap situation if the size is 300 to 400 MB already. Instead, more and more memory remains unused at the upper end of the program buffer.
7. The following situation only occurs on R/3 Release 4.6:
A batch job generates a lot of programs. Objects remain locked in the program buffer despite a COMMIT. In the ABAP debugger, you can check whether a work process locks many objects in the program buffer as follows: Change to the display of the system area (Goto -> System -> System Areas) and enter 'PXALOCKS' as the area name. The system will display a list of all objects in the program buffer. One column is provided for each work process. An 'x' indicates that the object is locked by the relevant work process. If a column contains a lot of 'x', the work process locks a lot of objects.
8. The following situation only occurs on AIX:
The short dump PXA_HASH_LOOP or PXA_NO_FREE_SPACE occurs immediately after the instance has been restarted.
Solution
In the text of the runtime error, check to see on which application server the error has occurred.
1. Check the number of PXA fragments on the affected application server. If required, reduce the number of fragments.
2. Check the setting of the parameter abap/buffersize (transaction RZ10 or report RSPARAM). For this, read doc:
103747 (R/3 Release 40A,40B,45A
97497 (R/3 Release 30C - 31I
3. Ask your system administrator to check whether the system resources are sufficient. (Utility program "ipclimits")
4. Due to the kernel patch with the text 'PXA: avoid illegal lock counter values' for Release 3.1I and 4.0B, the LOCK counter is no longer modified in the shared memory. As a result, invalid values cannot occur.
5. Refer to doc 175320
6. Refer to doc 121808
7. Due to the 4.6D kernel patch 185 with the text 'PXA: release program locks during COMMIT' locks on objects in the program buffer at the time of COMMIT are deleted. Thus, the affected objects can be displaced from the program buffer (provided that they are not locked by another work process).
8. Refer to doc 160875