by Aldo Bucossi
One of the most common ABAP dumps that you can experience using SAP Agent is the one identified with the Runtime Error "TSV_TNEW_PAGE_ALLOC_FAILED". Sometimes it is a standalone occurrence, in other scenarios it is instead repeatedly produced at a fixed interval, for example every 10 minutes, and in that case you could see also another Runtime Error, "TSV_TNEW_OCCURS_NO_ROLL_MEMORY" related to the SAP Agent User (default IBMMON_AGENT).
This problem occurs when, during the execution of a specific function module, there is no more free slots that can be allocated on the heap area or on the roll memory area. When it is associated to ITCAM SAP Agent user, it is usually related to the execution of function module /IBMMON/ITM_READ_STATFILE. This kind of scenario has been investigated in the past and the SAP Agent development team produced a set of Best Practices to avoid this problem. Basically, development team noticed that on some SAP environment, data collection for some attribute groups may lead to aforementioned ABAP dump due to system size and/or workload.
/IBMMON/ITM_READ_STATFILE is called by four function modules:
We can disable some of them to reduce the impact and the workload caused by /IBMMON/ITM_READ_STATFILE. In the Best Practice guide, that you can download from link:
You can find the steps to disable one or more of these function modules, in case you are not interested in the information provided by the related data collection. We are not going to describe here how to disable each of them because it is clearly documented in the Best Practice Guide. It is anyway important to know that some time, disabling one or more of the above function modules may be not enough to get rid of the ABAP dumps. Depending on workload peaks, the virtual memory available for the work processes may be anyway too small, causing the ITM Agent ABAP code (but it can occur also for other SAP users) to fail. In that case, it usually means that the sizing of the SAP system, for what concern the configuration of the virtual memory areas, is not able to cope with the workload peaks occurring from time to time.
Normally, a work process allocates pages from a memory area called Extended Memory, and continues to do so until it reaches the maximum value defined by the SAP parameter "ztta/roll_extension".
ztta/roll_extension = 2,000,000,000
After that, the work process switches in PRIV mode and starts using the heap area. The maximum heap size that a single work process can allocate is defined by parameters:
abap/heap_area_dia for dialog work process
abap/heap_area_nondia for non dialog work process.
Those values are specific for the single work process, so if you have for example:
abap/heap_area_dia = 2,000,000,000
It means that each user work process can allocate up to 2 GB of heap. There is another parameter called abap/heap_area_total that is instead the maximum amount of heap area for all users, and of course it is expected to be higher than the other two parameters. For example you can observe something like:
abap/heap_area_dia = 2,000,000,000
abap/heap_area_nondia = 0
abap/heap_area_total = 4,000,000,000
0 bytes in the heap_area_nondia means unlimited, but it is anyway dependant on the value of abap/heap_area_total
All the above parameters are kept within the SAP server instance profile.
In the ABAP dump output (ST22) you can find the amount of memory used at error time for each area.
For example, you can see something like:
|How to correct the error
| The amount of storage space (in bytes) filled at termination time was:
| Roll area...................... 6219056
| Extended memory (EM)........... 2002764512
| Assigned memory (HEAP)......... 2000041424
| Short area..................... " "
| Paging area.................... 0
| Maximum address space.......... 4294967295
If ztta/roll_extension parameter is set to 2,000,000,000, then from this panel we can understand that the work process used all the available Extended Memory and started using Heap memory. Now, if also abap/heap_area_dia is set to 2,000,000,000, this would explain the problem. Both areas reached the maximum allowed size and there is no more room.
It is possible there is a problem with the code that requests memory pages, but it is indeed also possible that the current resource configuration setting is not enough and SAP system needs more resources to cope with memory allocation requests received during peak periods. This is true especially on SAP systems having constantly high workload and additional workload peaks occurring from time to time. In this cases the SAP Agent ABAP code may experience above problems, and it is possible that disabling some of the function modules related to /IBMMON/ITM_READ_STATFILE does not completely fix the root cause.
You should consider, together with the SAP administrator, a review of the memory parameters I mentioned above. For example, increasing abap/heap_area_dia from 2GB to 3GB or higher, abap/heap_area_total from 4GB to 5GB or higher, ztta/roll_extension from 2GB to 3GB or higher. Please consider that changing system configuration parameters for SAP system has a direct consequence on the operating system resources used by the SAP processes. If the system does not have enough resources, for example physical memory and SWAP space, SAP system may show unexpected behaviours.
For this reason it is mandatory you evaluate any change related to SAP server profile with the SAP system admin.
Knowing the available Operating System resources and using the output of transaction ST06 and ST02, he can decide whether it is really possible to increase SAP server memory parameters without affecting operating system and without introducing problems or instability on SAP itself. Or, if the system itself needs to be upgraded assigning additional memory or SWAP space. You can find useful information about how SAP managed memory allocation starting from this link:
It can be for sure useful to have a clear understanding and to do the correct steps in fixing TSV_TNEW_PAGE_ALLOC_FAILED runtime errors.#HowTo#SAP#troubleshoot#ITM#Agent