SAP-TSV_TNEW_PAGE_ALLOC_FAILED资源瓶颈-热修改内存

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 the SAP application server. This guide will help you to analyze every occurrence and to conclude what team needs to be involved in the further steps of troubleshooting.
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). System protection mechanism. 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.
   Analysis of scenario #1:
   The required analysis begins in the ST22 transaction where more information on the dump can be checked. Once in ST22, select the desired occurrence 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 fields “EM” and “Heap” for education purposes):
   Memory consumption 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.

Roll… 0
EM… 2.000.000.000
Heap… 2.000.000.000
Page… 16384
MM used. 1157760496
MM free. 2294495840
With the following information in mind, we have to check what are the current memory parameters related 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):
Memory settings Looking at these parameter’s values brings us to conclude that the process that raised the shortdump could successfully 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.

em/initial_size_MB… 12.000
ztta/roll_extension… 2.000.000.000
abap/heap_area _dia… 2.000.000.000
abap/heap_area_nondia 2.000.000.000
abap/heap_area_total. 4.000.000.000
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, we 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 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.
Roll… 0
EM… 1.000.000.000
Heap… 0
Page… 16384
MM used. 1157760496
MM free. 2294495840
In order to confirm/ rule out that assumption, we move the 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.
Page area 0,12 308 11.512 131.072
Extended memory 14,69 1.679.360 12.000.000 12.000.000
Heap memory 0 100.509 0
That would be a perfect example of scenario #2.

Operating System Specifics
The quota of extended memory EM per platform is defined by:
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 transaction ST02. For additional AIX memory parameters, see SAP Note 789477.
Linux / Windows (es/implementation = map )
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.
Other UNIX platforms (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:
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

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 programs 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 (SAP or customer’s) to analyze the abnormal memory consumption. Most of the times it’s possible to increase the memory quotas up to a certain threshold with no depth understanding on the requirements of the associated application but this is entirely a system admin’s call to make. In case the affected program is indeed custom made and the parameters were already tuned (meaning that no more memory will be spared) then 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

简单点就是
se38 执行程序rsmemory，然后修改几个参数值，最后copy即可临时修改应用内存大小（注意服务器内存大小，重启后参数失效，永久修改可以改参数文件中的3个参数
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）