TSV_TNEW_PAGE_ALLOC_FAILED and TSV_TNEW_BLOCKS_NO_ROLL_MEMORY

[Former Member]

Hello,

Happy New Year 2007 to all!

We are using SAP R/3 4.6C, kernel 46D_EXT Patch 2271, Oracle 9.2.0.5 and HP-UX 11.23, 16GB RAM, 17GB swap.

Lately, at the end of this year, many ABAP runtime errors <b>TSV_TNEW_PAGE_ALLOC_FAILED and TSV_TNEW_BLOCKS_NO_ROLL_MEMORY</b> ocured.

Some times there is MEMORY_NO_MORE_PAGING.

I have read some notes regarding this issue.

1. Maybe I should increase the ztta/roll_area, current is 3000000 and to change into 6500000.

2. Can you please advice me regarding the rdisp/ROLL_SHM = 16384 (32768) and rdisp/ROLL_MAXFS = 80000 (131072), should I also increase them into the values in the brackets (there is a note which has the statement 'Must be adjusted if you change ztta/roll_area')?

3. What about the ztta/roll_first = 1 and ztta/roll_extension = 2000000000, should I also change them?

4. Regarding the Paging area, what should I do?

rdisp/PG_SHM = 8192 (32768) and rdisp/PG_MAXFS = 65536 (131072) , should I change into the values in the brackets?

em/initial_size_MB = 4092

THANK YOU in advance,

Ruzica

[Former Member · Accepted solution]

Hello Ruzica,

The MEMORY_NO_MORE_PAGING dumps are caused by a lack of SAP paging at the time and a seperate issue to the other dumps.

You should review the SAP paging usage history in ST02 and determine

if an increase in rdisp/PG_MAXFS is needed. This can be increased as

per note <a href="http://service.sap.com/sap/support/notes/133909">133909</a>. A 50% increase may be enough or sometimes more is

needed to avoid a similar situation where paging is exhausted.

There must be enough filesystem space for the new larger file size

for SAP paging if increasing, note <a href="http://service.sap.com/sap/support/notes/16513">16513</a> contains the following

also:

-

---

5. Pagefile and rollfile:

The files PAGFILnn and ROLLFLnn are normally located in the data

directory. Do not delete them while the system is online. If the

System is offline (but only then!!!), you can delete the roll and

page files. They are automatically created again during the R/3

System startup, and grow as necessary up to the allowed maximum.

Therefore, deleting them makes hardly any sense.

Exception: If the file has been enlarged beyond the normal size for

some special action (for example, client copy) the required disk

space can be retrieved by deleting the file. As mentioned above,

this may only be done when the instance is offline.

The maximum size of the roll file is given by:

(rdisp/ROLL_MAXFS - rdisp/ROLL_SHM) * 8 kBytes

A similar formula appplies to the paging file.

You can move the files to a different file system by defining other

values for R/3 parameters DIR_ROLL and DIR_PAGING.

-

---

General advice is as follows if you suspect that SAP paging usage

is too high for this system:

-

---

SAP Paging enables the roll area to be extended at ABAP runtime

when a large dataset, internal tables, for example, is handled.

SAP's memory management concept currently limits SAP Paging to

cases where the ABAP commands EXTRACT and EXPORT... TO MEMORY...

are used.

You can use SM04 -> Goto -> Memory to see a breakdown including

SAP paging usage for current times only.

The objects that continue to be stored in the SAP paging memory for

later releases can be divided into groups:

- ABAP data clusters stored temporarily with the ABAP statement

IMPORT/EXPORT FROM/TO MEMORY: This data is stored in the SAP paging

memory because it is not tied to a user context. The IMPORT/EXPORT

FROM/TO MEMORY statement exports the data from a user context via the

paging memory and then imports in another context.

- Parameters transferred when programs and transactions are called: A

new user context is created when an ABAP calls another program or

another transaction. The variables and lists transferred when the

relevant program is called or ended are likewise stored in the

SAP paging memory.

You may need to discuss this with users and ABAP programmers if

any Z-Programs are using a high amount of paging.

-

---

Regards, Mark

[Former Member · Accepted solution]

Hello Mark,

Thank you, your answers are very interesting.

Please look at the bellow parameters in our system:

Roll, extended and heap memory

ztta/roll_area 3000000

ztta/roll_first 1

ztta/short_area 1400000

rdisp/ROLL_SHM 16384

rdisp/PG_SHM 8192

rdisp/PG_LOCAL 150

em/initial_size_MB 4092

em/blocksize_KB 4096

em/address_space_MB 4092

ztta/roll_extension 2000000000

abap/heap_area_dia 2000000000

abap/heap_area_nondia 2000000000

abap/heap_area_total 2000000000

abap/heaplimit 40000000

abap/use_paging 0

System default value for (from RSPARAM):

1. rdisp/PG_SHM = 8192;

2. rdisp/PG_MAXFS = 32768;

3. rdisp/ROLL_SHM = 16384;

4. rdisp/ROLL_MAXFS = 32768.

<u>From ST02 (from one moment in time): </u>

SAP memory Current use Max. use In memory On disk

[%] [kB] [kB] [kB] [kB]

Roll area 7,45 47.672 68.856 131.072 508.928

Paging area 14,04 73.584 211.624 65.536 458.752

Extended Memory 62,82 2.629.632 4.186.112 4.186.112

Heap Memory 0 1.953.101

There is no other instance on the server.

What do you think?

Thanks in advance.

Ruzica

[Former Member · Accepted solution]

Hello Ruzica,

If this is the instance where the dumps happened, was it restarted recently as the low maximum values in ST02 indicate it was? If you go to the history section of ST02, what are the peak uses of SAP Paging and Extended Memory compared to now? The first screen of ST02 is giving maximum values since the last restart of the instance only but the history should contain the information of the day when the dumps happened.

I expect ST02 history to show that maximum usage of SAP paging was the buffer plus the file totalled at some point or closer to it. The main thing I notice is that em/initial_size_MB set to 4092 is very low, this is limiting the total EM for the instance to this amount, two large memory intensive reports can exhaust this alone (ztta/roll_extension of 2GB for each). With 16GB of RAM and no other instance on the host, you can increase this as needed towards the full 16GB (even above RAM is possible once you check performance and increase in increments). This change will help ensure that the EM per process can get the 2GB expected without being limited early by em/initial_size_MB. This will explain why the EM varied for the time of the dumps but heap was getting close to the 2GB of total each time which indicates that other reports were not using heap at the same time.

Regards, Mark

[Former Member · Accepted solution]

Hello Mark,

Yes, I should have told you, the previous day offline backup was performed on the instance, that's why the buffers are clean.

<b>Roll area sizes [kB]</b>

Used Max. used In SHM On disk

46.264 68.856 131.072 508.928 (today)

3.608 68.856 131.072 508.928

3.688 76.224 131.072 508.928

3.440 76.224 131.072 508.928

3.384 76.224 131.072 508.928

3.384 76.224 131.072 508.928

5.904 76.224 131.072 508.928

3.520 76.224 131.072 508.928

3.520 76.224 131.072 508.928

3.384 8.064 131.072 508.928

3.384 9.032 131.072 508.928

3.576 56.656 131.072 508.928

3.576 56.656 131.072 508.928

3.576 56.656 131.072 508.928

3.520 55.464 131.072 508.928

3.384 24.248 131.072 508.928

2.112 119.536 131.072 508.928

2.112 66.040 131.072 508.928

3.384 8.472 131.072 508.928

3.384 8.472 131.072 508.928

3.744 54.456 131.072 508.928

4.048 54.456 131.072 508.928

<b>Page area sizes [kB]</b>

Used Max. used In SHM On disk

69.968 211.624 65.536 458.752 (today)

56 211.624 65.536 458.752

56 524.280 65.536 458.752

56 524.280 65.536 458.752

56 524.280 65.536 458.752

56 524.280 65.536 458.752

7.632 524.280 65.536 458.752

56 524.280 65.536 458.752

56 479.912 65.536 458.752

56 16.072 65.536 458.752

56 16.552 65.536 458.752

56 278.512 65.536 458.752

56 278.512 65.536 458.752

56 278.512 65.536 458.752

56 271.592 65.536 458.752

56 118.384 65.536 458.752

32 290.640 65.536 458.752

32 256.112 65.536 458.752

56 16.096 65.536 458.752

56 16.096 65.536 458.752

56 360.872 65.536 458.752

56 360.872 65.536 458.752

<b> Extended memory sizes [kB]</b>

Used Max. used Available

2.543.616 4.186.112 4.186.112 (today)

77.824 4.186.112 4.186.112

73.728 4.186.112 4.186.112

69.632 4.186.112 4.186.112

69.632 4.186.112 4.186.112

69.632 4.186.112 4.186.112

180.224 4.186.112 4.186.112

73.728 4.186.112 4.186.112

77.824 4.186.112 4.186.112

69.632 139.264 4.186.112

69.632 126.976 4.186.112

73.728 3.178.496 4.186.112

73.728 3.178.496 4.186.112

73.728 3.178.496 4.186.112

77.824 3.178.496 4.186.112

73.728 1.245.184 4.186.112

73.728 4.186.112 4.186.112

77.824 4.186.112 4.186.112

69.632 462.848 4.186.112

69.632 462.848 4.186.112

77.824 4.186.112 4.186.112

86.016 4.186.112 4.186.112

How it looks like?

Can I shortly resume about the memory parameters?

1. em/initial_size_MB, regarding the 16GB of the RAM, should I increase to example: 8188 (the maximum value in RZ11 is 8196)?

2. ztta/roll_area to 6500000 ?

3. What about the rdisp/PG_MAXFS should it be increased for 50% = 131072 ? And the rdisp/PG_SHM to increase to 32768 ?

4. What do you think about the ztta/roll_extension = 2000000000, should I increase or to decrease the parameter?

5. And the roll area is there need to change the rdisp/ROLL_SHM = 16384 (32768) and rdisp/ROLL_MAXFS = 80000 (131072)?

Thanks in advance.

Many regards,

Ruzica

[Former Member · Accepted solution]

Hello Ruzica,

Not looking healthy currently without some changes

The history is indicating that the SAP paging area was exhausted at times in the past and also total of EM (The maximum in ST02 resets after each restart of the instance so it the history doesn't indicate that EM was exhausted each day of the past week, even though this is possible also).

- The value of em/initial_size_MB can be increased higher than 8GB (notes <a href="http://service.sap.com/sap/support/notes/146289">146289</a> , <a href="http://service.sap.com/sap/support/notes/835474">835474</a> and <a href="http://service.sap.com/sap/support/notes/182067">182067</a> have more information) and you can ignore the warning from RZ11. Monitoring ST02 will indicate how high you need to rise this to avoid exhuasting total EM for the instance but there should not be performance issues with increasing to towards the total of RAM if needed eventually.

- I would advise ztta/roll_area is set to 6500000.

- Parameter risp/PG_MAXFS should be increased by 50% initially, later increases may be needed also. If the SAP Paging usage is higher than you expect later then you can investigate the reason via SM04 as mentioned earlier. Parameter rdisp/PG_SHM should be set to the default value in RSPARAM unless recommended otherwise by TCC or others for performance reasons.

- I recommend that ztta/roll_extension is left at 2000000000. If a report dumps with 2GB of EM used and nearly 2GB of heap then this normally indicates that the data selection needs to be reduced or there is an issue that is specific to the that report running. (One reason to reduce ztta/roll_extension is if there was only limited RAM on the host and em/initial_size_MB could not be increased further and you wanted to avoid total EM being exhausted, a reason to increase ztta/roll_extension is if there was lots of resources to increase em/initial_size_MB and you had reports that need to use more EM than 2GB without fear of exhausting all EM).

- Usage of SAP roll is very low, the values of rdisp/ROLL_SHM and rdisp/ROLL_MAXFS don't need to be changed. The defaults according to RSPARAM should be fine.

Hope this helps.

Regards, Mark

[Former Member · Accepted solution]

Hello Mark,

Thanks for all your information. It's very good, helpful and understanding.

This Sunday I'll try to change the parameters in rz10 and restart the instance:

1. em/initial_size_MB = 8196,

2. ztta/roll_area = 6500000 and

3. rdisp/PG_MAXFS = 131072.

I hope everything will be good.

Many regards,

Ruzica

[Former Member · Accepted solution]

Hello Ruzica,

Don't forget to monitor in ST02 afterwards if further increases in em/initial_size_MB or rdisp/PG_MAXFS are needed. I expect that when these are sized as needed for the instance there will not be repeats of the various dumps unless ztta/roll_extension is itself reached in the memory used of a dump and heap total reached also as expected.

Regards, Mark

[Former Member · Accepted solution]

Hello Mark,

I've also inform our ABAP Developers to look in some custom developed Z_* programs which I found to be using very much of the Memory in sm04.

Maybe some changing in some reports will also be useful and will solve the problems.

But, I have to do my<b> basis</b> job, tune and change parameters.

Thanks for all your help.

Regards,

Ruzica

[Former Member · Accepted solution]

Hello Mark,

Just one think more.

What about the em/max_size_MB?

I need to change it also to 8196 just like em/initial_size_MB?

I read some notes saying about this warning.

Many regards,

Ruzica

[Former Member · Accepted solution]

Hello Ruzica,

Parameter EM/MAX_SIZE_MB doesn't need to be changed. This parameter is relevant for certain platforms only and was replaced by EM/TOTAL_SIZE_MB as of Kernel 46D Patch Level 570. Note 425207 has some more details.

Regards, Mark

[Former Member · Accepted solution]

Hello Ruzica,

Glad you found some suspects. The proposed change is not too severe to the SAP Paging file but if more and more increases are needed then it will become more important to investigate the reasons. Going to the file after the buffer is exhausted means performance dips especially if it is constant high usage of SAP paging.

Regards, Mark

[Former Member · Accepted solution]

Hello Mark,

I was planning to change the em/initial_size_MB, ztta/roll_area and rdisp/PG_MAXFS with rz10, save and activate the profile. After the offline backup which is also planned for Saturday early in the morning, the DB and the instance will be restarted and the new version of the profile will be active.

I was also planning to test the functionality in the system after the parameter changes. But, today, I've got request from our ABAPers to check and prepare the system, make security backups, for some project "Going Live" and on the weekend, starting on Saturday, we'll do import of transports and tests.

Is there a changes any problems to ocur after increasing the above profile parameters?

Because I will reschedule the profile changes for the other weekend in order to have time to test and be sure.

Thanks again,

Regards, Ruzica

[Former Member · Accepted solution]

Hello Ruzica,

With the amount of RAM you have and the fact that there are no other instances on the host, there should be no issues with these changes. The increase in rdisp/PG_MAXFS may mean a slight dip in performance if SAP paging usage is higher than current maximum at all times but should not be very noticable.

Regards, Mark

[Former Member · Accepted solution]

Hello Mark,

My problem has been solved.

I have stopped changes for the memory parameters. We implement one SAP Note regarding the problematic Z_* program which was extremely increasing the Total memory and Page, and gets many wp with PRIV.

It seems that this was the problem!

One week without any Memory dump.

But, as we mentioned in the previous posts, I have prepared new profile and after one another good week, I will increase the parameters.

Thanks for all,

Many regards,

Ruzica

[Former Member · Accepted solution]

Hi,

We are facing the same issue related to RSCRM_BAPI background job.

The job is cancelling with the TSV_TNEW_PAGE_ALLOC_FAILED or TSV_TNEW_BLOCKS_NO_ROLL_MEMORY.

We tried few notes but not solved. plz give details how this was resolved.

Some times the same issue is occurring for Precalculated query.

We did recently upgrade from 3.x to BI7.0. Jobs worked fine before upgrade.

Please suggest how it can be resolved.

Thanks,

Joseph

[Former Member · Accepted solution]

Hi Ruzica,

Could you please share the solution with us.

Even i am getting this error, while i runa Z program on batch job. It will be great if you share that thoughts here, as this issue is been dumping in production since for a while.

Thanks in advance,

Kiran

[Former Member · Accepted solution]

Ruzica,

Can you please share which OSS note resolved your problem? We also have a z program that is causing dump with the same error message.

Thanks,

Padma

panantha@sunocoinc.com

[Former Member · Accepted solution]

Hi Ruzica,

Could you please post the note number as we are facing the same problem.

Thank you

[Former Member · Accepted solution]

Hi All,

Anyone knows what was that Note number?

Regards,

Gabor

[Former Member · Accepted solution]

PLEASE NO-ONE REPLY ANYMORE TO Ruzica Kalkasliev .

Ruzica: if you have the answer to one problem, you should share it with the others, as when you have a problem everyone will help you.

Please show some respect to the others who are facing the same issues.

[Former Member · Accepted solution]

having the same issues, anyone figured what's the note he talked about?

[Former Member · Accepted solution]

hi Ruzzia..

please share the note number

Thanks & Regards,

Abhilash

[Former Member · Accepted solution]

Note 1007749 - DataSource replication: Shrt dump TSV_TNEW_PAGE_ALLOC_FAILED

Try this one.

[Former Member · Accepted solution]

Mark

You seem to have a really good understanding of the details behind the memory allocation i can figure that out from your response.

Have you published any white paper or blogs to share the knowledge ? if yes please paste the link here.

If not i would request you to do so

Cheers !

Manish

[Former Member · Accepted solution]

Hi Mark,

    I have one question regarding these memory configuration..is this extended memory resides on RAM or swap? and whats this paging memory actually mean for?

Rgds,

Bansri

[Former Member]

Hello Ruzica,

The reason for the TSV_TNEW_PAGE_ALLOC_FAILED and TSV_TNEW_BLOCKS_NO_ROLL_MEMORY dumps is normally that you are hitting limits per process or per instance for heap and extended memory.

Parameter rdisp/ROLL_SHM should remain unchanged and rdisp/ROLL_MAXFS only increased if ST02 is indicating it is close to being exhausted which I don't expect. Maybe you could post the usage of SAP paging, SAP roll, EM and Heap for this instance from the initial screen of ST02?

Use the note <a href="http://service.sap.com/sap/support/notes/146289">146289</a>(Parameter Recommendations for 64-Bit SAP Kernel) for values of ztta/roll_area and ztta/roll_first. Setting ztta/roll_area to 6500000 in itself should not mean increases in the other parameters.

What are the default (right hand side) values from SE38 -> RSPARAM for rdisp/PG_SHM, rdisp/PG_MAXFS, rdisp/ROLL_SHM and rdisp/ROLL_MAXFS?

What are the values of the following:

abap/heap_area_dia

abap/heap_area_nondia

abap/heap_area_total

em/initial_size_MB

Are there any other instances installed on this host of 16GB RAM?

The answer to these questions will help determine if parameter changes will help or if data selections of the reports causing these dumps need to be reduced to avoid these dumps.

Thanks, Mark

[Former Member]

Before changing any parameter ( if the system was working well before this bout of dumps and u havent changed anything), i would check the follwoing

Are the dumps across the board or happening only for some particular programs

The values of the memory paramters (extended , heap etc) captured by the dumps

Do the values look realastic comapred to what you have set

The swapinfo on your OS

thanks

Naushad

[Former Member]

Yes, it seams to be the internal table IT_30 and some custome-made Z_... program

In case of <b>TSV_TNEW_BLOCKS_NO_ROLL_MEMORY</b>:

Roll area...................... 2507408

Extended memory (EM)........... 1556243755 or 2000305812 or 1037050977

Assigned memory (HEAP)......... 1928325488 or 1998593376 or 1979245248

Short area..................... 16079

Paging area.................... 49152 or 57344

Maximum address space.......... "-30553184"

In case of <b>MEMORY_NO_MORE_PAGING</b>:

Roll area...................... 16128

Extended memory (EM)........... 48170595

Assigned memory (HEAP)......... 0

Short area..................... 0

Paging area.................... 24576

Maximum address space.......... "-30553184"

At OS level the system usualy does not swap.

Thanks,

Ruzica