TSV_TNEW_PAGE_ALLOC_FAILED MC.1

[20167459]

dump-tsv-tnew.txtGreetings.

We have a dump "TSV_TNEW_PAGE_ALLOC_FAILED" in production environment when executing transaction MC.1
and in other "z's" programs, I have managed to reproduce the error when executing the MC.1 transaction in the quality environment, it is worth mentioning that
the transaction is executed with the "Plant" fields and with the range of 1 month, I have been able to execute the report, increasing
the following parameters:

abap/heap_area_dia= 10737418240
abap/heap_area_nondia= 10737418240
abap/heap_area_total= 12884901888

achieving that I finished the report without presenting the aforementioned dump, however I have not found notes that make me a recommendation of the minimum and maximum value in these
parameters and I have the following doubts:
What is the limit that I can configure for these 3 parameters?
Do I need to consider other parameters in addition to those already mentioned above?

I share the data of my system:
SAP Release: 740
Operating system: AIX
64 bits
Release: 7.1
SAP kernel: 749
Memory Ram: 16GB in an applicative 26 and 32GB in others two applicative 44 and 47
CPU: 16

Dump data which also attached TXT file "Dump TSV_TNEW_PAGE_ALLOC_FAILED.txt"

Memory consumption
Roll.... 0
EM...... 2000579232
Heap.... 6590517648
Page.... 32768
MM used. 8586771328
MM free. 1036128

[dasistdochscheisse · Accepted solution]

If you run a transaction in dialogue, it first uses extended memory (EM) until the quota is reached (ztta/roll_extension) or the whole EM is exhausted (em/initial_size). Imagine, you have 10 GB EM, some users use in total 9.5 GB and the quota is 2GB. The next user can only use 0.5 GB, regardless of the quota. When there is no more EM, the work process uses heap memory. Heap memory is bound to the work process (EM is not, it can be rolled in/out of a work process), so the work process goes into PRIV mode, meaning even though the user is not using the woork process it is not free for others. For heap it's the same, there is a quota for each user and a total quota for all.

The total use of EM and heap can be seen in ST02. If you double click in the 'EM-line' and then click on "Ext Memory Blocks" you see who uses how much memory.

In your case it looks like both quotas for EM were reached (2+10 GB) So you can increase the single user quotaone of them *if* there is EM or heap left or the total quota if there is memory on the os unused. The report RSMEMORY let's you change the quota and the total amount for both during runtime, but the new values are gone after a restart of the system.

Another possibility: ask the user to not use so much data meaning do a better selection. Most will say they cannot do that for some unknown reason ;-). 12 GB RAM for one transaction is pretty much. You can also ask the developer of your z-programs to do a better job.

[Sriram2009]

Hi Hector

1. First you have to find that the transaction is either standard or Z programs, why read so many records during the execution time? for that, you have to enable the ST12 trace to find which SQL statement takes a long duration? refer to the blog

https://blogs.sap.com/2009/09/08/single-transaction-analysis-st12-getting-started/

2. For the dump you can refer to the SAP Note 2180736

Regards

SS