ABAP Dumps are one of the basic means of troubleshooting system issues. Here are some commonly occurring memory related short dumps and how to deal with these dumps.
Dumps starting with ‘TSV_TNEW_’
When a work process requests for memory, the allocation is first from “Extended Memory” based on profile parameters ‘roll_extension’ and ‘initial_size_MB’ (in case of implementation variant UNIX_STD; or TOTAL_SIZE_MB in case of SHM_SEGS AIX).
If the request for memory fails, memory allocation is attempted from “Private Memory” of the work process.
If that allocation also fails, a runtime error “TSV_TNEW_PAGE_ALLOC_FAILED” error is reported.
The dump TSV_TNEW_BLOCKS_NO_ROLL_MEMORY means that the roll buffer has been exhausted.
Each transaction requires some main memory space to process application data. If the operating system cannot provide any more space, for example while initiating the memory for an internal table, the transaction is terminated and the program terminates with the error TSV_TNEW_OCCURS_NO_ROLL_MEMORY.
TSV_TNEW_OCCURS_NO_ROLL_MEMORY occurs if the first allocation to an internal table fails, while other TSV_TNEW_* dumps occur at later stage of allocation request failure.
Dealing with TSV_TNEW_* dumps
1. Check if inappropriate selection criteria has lead to a spike in the demand for memory. Advise the end user to restrict the selection criteria.
2. Check if memory intensive programs or transaction are being run in parallel. You can make that out with multiple dumps. Distribute the transactions or programs by time or application servers.
3. Search SAP notes matching the program name or transaction, and the dump to look for known program errors. Memory leaks can cause exhaustion. ABAPers should check for possible optimizations in Z programs.
4. If selection criteria cannot be controlled or program cannot be optimized
- Review the parameters “ztta/roll_extension” and “em/initial_size_MB” (for HP-UX and AIX UNIX_STD) or “EM/TOTAL_SIZE_MB” (for AIX SHM_SEGS). If es/implementation = map in Linux, review the parameter em/address_space_MB.
- Apart from Extended memory parameters, the SAP parameters for ‘private memory’ “abap/heap_area_dia”, “abap/heap_area_nondia” and “abap/heap_area_total” can be adapted. Heap memory can be increased temporarily (on the fly) without restarting the system by using the report RSMEMORY.
- Check whether the parameter changes could lead to more memory demands against the OS (“sappfpar check pf=<profile>”). This program determines the storage resources required by the SAP server using the parameters that are currently set.
- Run “memlimits -v off” (On HP-UX, it is best to execute the program when the SAP system is shut down). This program checks the limits of the available operating system storage resources.
5. If you notice TSV_TNEW_BLOCKS_NO_ROLL_MEMORY, apart from applying the above steps, check the following:
- Call transaction ST02 > detail analysis menu > history/buffer statistics > Roll & page area
- If the roll buffer has been exhausted, increase the size with parameter rdisp/ROLL_MAXFS, however make sure there is sufficient disk space to handle the additional size of this buffer if it writes to disk.
6. If you notice TSV_TNEW_OCCURS_NO_ROLL_MEMORY dumps, check if there are other dumps at the same time. The dumps are usually accompanied by other TSV_TNEW* dumps or SYSTEM_NO_SHM_MEMORY.
If this dump is accompanied by SYSTEM_NO_SHM_MEMORY, increase parameter abap/shared_objects_size_MB to a higher value and restart the SAP instance to take effect. Consult “Related Notes” section of SAP Note 1322182 for guidance on choosing the value for certain applications.
7. If the failure occurred even though the limits on roll, extension or heap memory were NOT hit, check if you see SYSTEM_NO_ROLL error with a line similar to “Unable to fulfill request for XYZ bytes of memory space”. If you see this, check the current value of ztta/max_memreq_MB. This parameter limits the amount of memory that can be allocated by a single call.
If the SOLUTION points 1, 2 and 3 are not applicable, increase ztta/max_memreq_MB.
Ensure that the change does not violate this condition:
ztta/roll_extension < (4096 – ztta/max_memreq_MB) * 1024 * 1024 – 1
STORAGE_PARAMETERS_WRONG_SET dumps
This error occurs if the SAP System attempts to allocate memory areas from the memory area ‘HEAP’. However, this memory is exhausted, although the limit abap/heap_area_dia or abap/heap_area_nondia is not yet reached.
These profile parameters are obviously not checked against the available SWAP memory on the application server.
Dealing with STORAGE_PARAMETERS_WRONG_SET dumps
1. Note the value that is given as the allocated memory under ‘What happened’ in the short dump, and subtract a nominal value ex: 10000000 from it.
2. Set the system profile parameter ABAP/heap_area_nondia to this value. If the parameter ABAP/heap_area_dia is now larger than ABAP/heap_area_nondia, set this parameter to the noted value as well.
3. Restart the SAP System.
SYSTEM_NO_SHM_MEMORY and CX_SHM_* dumps
This error occurs if the current application server no longer has sufficient shared objects memory available to store the data in a shared objects area.
This error can also occur if the shared object memory is highly fragmented. Normally, this is not a problem because the data of an area instance can be distributed to several memory blocks that do not have to be connected. However, this is not possible for some memory objects; for the index of a hash table for example. If a connecting memory block that is sufficiently large is not found for one of these objects, the termination occurs even though the accumulated free memory would be sufficiently large.
Dealing with SYSTEM_NO_SHM_MEMORY and CX_SHM_* dumps
1. You can use transaction SHMM to analyze the current usage of shared objects memory. The “Shared Objects Memory” title element shows the amount of free and the amount of currently used shared object memory.
2. With the analysis report RS_SHO_GET_LARGEST_MM_BLOCK, the system can display a list of the largest free memory blocks in the shared objects memory. This enables you to determine whether there is actually a high fragmentation.
3. Regardless of the reason for the error, the problem can be fixed by increasing abap/shared_objects_size_MB in steps of double the value until the dumps stop occuring.
4. While changing abap/shared_objects_size_MB on AIX, ensure that the condition “em/global_area_MB + abap/shared_objects_size_MB + (em/blocksize_KB / 1024) < (ES/SHM_SEG_SIZE -1)” is not violated.
5. Consult “Related Notes” section of SAP Note 1322182 for guidance on choosing the value for certain applications.
PXA_NO_SHARED_MEMORY dumps
This error occurs if the program buffer could not be created with the size specified in the profile parameter abap/buffersize (KB).
This could be because of insufficient memory/swap space on the system.
Shared Memory segment 6 (PXA –abap/buffersize) is the last one allocated, so you may not see issues with other segments.
The application server goes into the “emergency mode” and the system attempts to create the program buffer with size of 4 MB for each work process or 32 MB in the shared memory, depending on the release level or patch level of the kernel. In the emergency mode, only two work processes (w0 and w1) are started. If this attempt also fails, all work processes terminate with an initialization error.
Dealing with PXA_NO_SHARED_MEMORY dumps
1. Check if the shared memory sizes or abap/buffersize is set to a very high value. If this is too high, try reducing the parameter values.
2. Increase swap space (20 GB + 10 GB for each additional instance).
3. If this problem is occuring after restart of an instance while other instances on the host server were running, restart all the instances with cleanipc on AIX.
PXA_NO_FREE_SPACE dumps
Almost always, one of the following cases is the cause for runtime error PXA_NO_FREE_SPACE:
1. 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.
2. The size of the program buffer is too small.
3. Due to missing shared memory, the program buffer cannot be created in the size entered in the parameter abap/buffersize.
Dealing with PXA_NO_FREE_SPACE dumps
1. The program buffer is divided into several fragments to allow several change accesses to the buffer to take place in parallel.
The number of fragments is a function of program buffer size, CPU, number of work processes and type of machine.
It could happen that one of the fragments is filling up faster while the others are underused. This causes ineffective use of the program buffer.
- Check if there are too many swaps in a fragment by debugging. Execute /h in OK field (where you type in transaction codes). Run any transaction. In Debugger menu, select the option Switch to classic debugger. Execute “dis” in OK field. Type PXAFRAG in Area and press enter.
- To fix this, limit the number of fragments to 1 by setting the parameter abap/buffer_fragments = 1
2. Call transaction ST02. Check if displacements occur in the “Swaps” column for program buffer. Up to 10000 swaps are regarded as a normative behavior of a program buffer.
- If there are more than 10K displacements, check the Freesp. KB and FreeDirEnt values. If both values or Freesp. KB are nearly 0, increase abap/buffersize. After increasing abap/buffersize, run “sappfpar check pf=<instanzprofil>” and apply suggestions to avoid memory issues.
- During normal use of the program buffers, there is seldom more than 10% of the directory entries in use. If FreeDirEnt is nearly 0 (likely in BW system), increase the parmeter abap/programs.
- By default abap/programs = abap/buffersize / 4. Set abap/programs = abap/buffersize.
3. If program memory could not be created, this dump will be accompanied by PXA_NO_SHARED_MEMORY error. Please see the section for PXA_NO_SHARED_MEMORY error.
PXA_DESTROYED dumps
The PXA_DESTROYED short dump is reported if the administrative data of the program buffer is destroyed.
All work processes are informed to wait for the PXA semaphore lock to be released. The administrative data of the program buffer is then initialized again – the program buffer is “logically seen” to be empty.
As the objects in the program buffer are not physically deleted, work processes can continue to work after the semaphore lock is released.
One of the reasons for PXA_DESTROYED short dump is small limit on the number of directory entried for PXA.
This is usually the case in BW systems:
In addition to ABAP programs, the PXA buffer also contains structures. When you execute BW queries, structures are created dynamically and these are released after you execute the query.
This also happens with the BW input help. If the input help is automated, for example, called in transfer rules, the number of PXA directory entries provided by default may not be sufficient.
In this case, obsolete entries are deleted by the PXA garbage collector to create space for new entries. If the garbage collection doesn’t delete all the obsolete entries, it leads to an overflow of program buffer. If you have an overflow, all directory entries of the fragment in question are deleted.
Dealing with PXA_DESTROYED dumps
Call transaction ST02. Check if displacements occur in the “Swaps” column for program buffer. Up to 10000 swaps are regarded as a normative behavior of a program buffer.
Check if FreeDirEnt is nearly 0. If this is the case, increase the parameter abap/programs.
By default abap/programs = abap/buffersize / 4. Set abap/programs = abap/buffersize to eliminate the overflow in the PXA directory.
If FreeDirEnt is not nearly 0, the problem could be due to a kernel bug.
