TSV_TNEW_PAGE_ALLOC_FAILED

Skip to end of metadata

Created by Ian Segobio, last modified on Jun 30, 2015
Go to start of metadata

Purpose
This document's intent is to help customers with the analysis and resolution of the
TSV_TNEW_PAGE_ALLOC_FAILED shortdump, which is not an error or bug in the software but
purely related to customizing of resources on SAP application server. This guide will help you to
analyze every occurence and to conclude what team needs to involved in the further steps of the
troubleshooting process.

Overview
First and foremost, we have to keep in mind that this shortdump will be raised in one of the following
scenarios:
#1. A single work process attempts to allocate more memory than it is allowed (alone). Protection
mechanism of the system. Current system load is irrelevant.

#2. System is busy and there are lots of processes requesting memory. In this scenario, the current
memory usage is high. As soon as the very next work process requests an amount that crosses the
threshold of the global total of memory, we have the shortdump.

ANALISYS OF SCENARIO #1:

The required analysis begin in ST22 transaction where more intel on the dump can be checked.
Once in ST22, select the desired occurence of TSV_TNEW_PAGE_ALLOC_FAILED and scroll to
the "Memory consumption" area. This area reports the memory usage at the time of the dump. We
have below one example of such information (please be aware that the dots were added in filelds
"EM" and "Heap" for education purposes):
Memory consumption

Roll....
EM......
Heap....
Page....
MM used.
MM free.

0
2.000.000.000
2.000.000.000
16384
1157760496
2294495840

The shordump information for this occurrence in specific, tells us that the process has used 2 GB of
extended memory (EM) plus 2 GB of heap memory (Heap). We then conclude that at the time of the dump, a
little bit more than 4 GB of memory was being used by the process, which failed as no more memory could
be provided.

With the following information in mind, we have to check what are the current memory parameters
reltaed to the values that we just saw. One way to do it, is through transaction ST02. From ST02,
you can click twice on "Extended memory" field and then "Current parameters". On that screen, we
are interested in the following parameters (please be aware that the dots were added for education
purposes):
em/initial_size_MB
ztta/roll_extension
abap/heap_area_dia
abap/heap_area_nondia
abap/heap_area_total

12.000
2.000.000.000
2.000.000.000
2.000.000.000
4.000.000.000

Looking at these parameter's values brings us to conclude that the process that raised the shordump could
sucessfuly allocate the full assigned memory quota for Extended memory "ztta/roll_extension" and assigned
quota for HEAP memory which can break into one of the two following parameters: "abap/heap_area_dia" for
a dialog process OR "abap/heap_area_nondia" for a non dialog one.
See specific parameters / platform below.

If the work process could allocate all of the amount available for a single process, for both
EXTENDED MEMORY and HEAP areas and yet failed, wen can conclude that this case fits into
scenario #1 described above.

ANALYSIS OF SCENARIO #2:

Lets assume the same dump happened and we are heading for the analysis just as in the previous
example. This is what we see in the consumption area:
Memory consumption
Roll.... 0
EM...... 1.000.000.000
Heap.... 0
Page.... 16384
MM used. 1157760496

MM free. 2294495840
Now we have a slightly different scenario. We already know that a maximum of 2 GB of extended memory is
available for that process but still it has dumped after having used only 1 GB. The only explanation would be
that there are no other 1GB available for the application server as a whole.

In order to confirm/ rule out that assumption, we move tha analysis once again to ST02 transaction.
Our focus is once again on the SAP MEMORY tab. We look now to the "Extended memory" field
where simple by relating the two fields "MaxUse" and "In Mem", its possible to confirm that, at least
once in the current uptime, all of the extended memory was used. Assuming that it was our dump the
responsible, the current Extended memory of the instance was around 11GB (from the 12 GB
available) and our program has allocated just the 1GB that not yet taken.

SAP Memory

Curr.Use %

CurUse[KB]

Page area

0,12

308

Extended memory

14,69

1.679.360

12.000.000

12.000.000

100.509

Heap memory

MaxUse[KB]
11.512

In Mem[KB]
131.072

That would be a perfect example of scenario #2.

OPERATING SYSTEM SPECIFICS:

The quota of extended memory EM per platform is defined by:

a) AIX (ES/TABLE = SHM_SEGS)
ztta/roll_extension: Defines the quota of extended memory (EM) in the excerpt above. If the value
shown in the dump for EM is much lower than this parameter it is generally because the total amount
of EM that can be allocated by ALL sessions of an application server has been reached. This can be
confirmed in tx. ST02.
For additional AIX memory parameters, see SAP Note 789477
b) Linux (es/implementation = map) and Windows:
ztta/roll_extension
em/address_space_MB: This parameter specifies in MB the size of the address space that is
provided for the memory class "Extended Memory" in a work process. Therefore, it should be set
higher than ztta/roll_extension.

For additional information regarding memory management on Linux with MAP implementation,
see SAP Note 386605.
For additional information regarding memory management on Windows, see SAP Note 88416.
c) Other UNIX plaforms (ES/TABLE = UNIX_STD implementation):
ztta/roll_extension: see case "a".
For additional information regarding memory management on Linux 64 bit (ES/TABLE =
UNIX_STD), see SAP Note 941735.

The quota of Heap memory is set by the following parameters:

On all operating systems (i.e. Heap parameters are operating system independent)
abap/heap_area_dia: Heap memory quota (HEAP) for dialog work processes.
abap/heap_area_nondia: Heap memory quota (HEAP) for non-dialog work processes.
abap/heap_area_total: Heap memory quota all work processes can allocate in total.
Memory quotas can be increased temporarily (on the fly) without restarting the system by running
program RSMEMORY. For details, refer to The rsmemory Report. If the system is a production one,
this could be the best way for already known progrmas consuming memory quotas.

The total Extended memory available is set by the parameters:

a) AIX (ES/TABLE = SHM_SEGS)
EM/TOTAL_SIZE_MB: This parameter limits the TOTAL amount of Extended Memory that can be
allocated by ALL sessions of an application server.
b) Linux (es/implementation = map) and Windows:
em/max_size_MB: This parameter limits the TOTAL amount of Extended Memory that can be
allocated by ALL sessions of an application server.
c) Other UNIX plaforms (UNIX_STD implementation):
em/initial_size_MB: This parameter limits the TOTAL amount of Extended Memory that can be
allocated by ALL sessions of an application server.

As of kernel 7.40, availability of Zero Administration Memory Management is available for all
platforms (see SAP Note 2085980).

CONCLUSION:

In any of the below described cases, where it is confirmed that the memory mechanism works as
designed, it falls to the application team to analyze the abnormal memory consumption. Of course
the related memory parameters can be adjusted in case the server case spare extra memory but this
is entirely a system admin's call to make.
If it's a Z (custom) program that is raising the exception and all the related memory parameters are
already tuned, meaning that no more memory will be provided, the customer team which developed
the application should perform this analysis.

Related Content
Platform-Specific Description of Memory Management
Related Documents
ztta/roll_extension_dia: EM Quota for Dialog Processes
abap/heap_area_total: Total Quota for Heap Memory
abap/heap_area_dia: Heap Memory Limit for Dialog Work Processes
Related SAP Notes/KBAs