LOAD_NO_ROLL on Kernel 7.41 - Roll Area gone?

[Former Member]

Has anyone encountered problems with the latest 7.41 Kernel? Since we upgraded our ERP system to use this kernel we are now getting frequent LOAD_NO_ROLL error. The nature of the shortdump is as follows

----------------

Error analysis

This is probably due to a very large dataset, for which there are

insufficient resources in your installation.

When loading a program, 196608 bytes of storage space was

needed, but this was not available.

Last error logged in SAP kernel

Component............ EM

Location.......... SAP-Server server_SID_01 on host server (wp 15)

Version.............. 37

Error code............ 7

Error text............ Warning: EM-Memory exhausted: Workprocess

gets PRIV

Description............

System call..........

Module.............. /bas/741_REL/src/krn/em/emxx.c

Line................ 2369

The error reported by the operating system is: Error number.....

Error text....... " "

-------------------

And there are so many of these in a span of a few minutes while I suspect the EM is exhausted.

As you can see the transaction resulted to a short-dump as there is no more Extended Memory available for even to load the program (even for a very small <200KB) to memory.

With the new Memory Management of 7.41, SAP had removed the Roll Area (so ztta/roll_first and ztta/roll_area are no longer there)

What this means is every transaction now will go straight into the Extended Memory (even just loading the program to memory for the engine to execute the transaction). In the past from my understanding there is always guaranteed space for the program to load as ztta/roll_first of 1MB (even how small it is) is available; then when the program executes of course when transaction context cannot fit into that area then it starts using the roll memory, then Extended Memory, and finally the Heap Area. With 7.41 it is really just straight to EM then Heap.

The problem I am having is when the EM is exhausted, new transactions result to the above shortdump.

The easy fix might be to increase the Extended Memory (em/initial_size_MB) but may not be the cheapest option as EM is dependent on the size of RAM (i.e. we need to increase RAM to get a bigger EM)

The other option is to maybe reduce the amount of EM that each user session is able to allocate (i.e. reduce the size of ztta/roll_extension), which means there will be more EM (from EM total) available for the other users to use.  If we do so, how much ztta/roll_extension is good if my em/initial_size_MB is 10GB? (not minding the effect of individual sessions going to Heap faster)

[dominik_kastner · Accepted solution]

Hy, i think the following note is relevant for you:

2084001 - Many short dumps LOAD_NO_ROLL, many work processes in PRIV mode

[Former Member · Accepted solution]

Thanks! We've worked with SAP and convinced them to fix the bug!

I should probably get some credit of that SAP note!

[former_member243992 · Accepted solution]

Hi Donald,

I have gone through the SAP note , but my concern is like I am not getting the dump but there is huge memory leak found the system. Can you please tell me that is there any kind of memory leaking bug reported on 741_REL /SP 50 ?

Could you please provide me some SAP Note regarding it.

[Former Member · Accepted solution]

Hi Donald ,

Do you have any info about any EM leaking bug reported in SAP kernel 741_REL ? in Patch level 50?100?

[Former Member · Accepted solution]

Hi Biswajit,

Yes I think the bottomline there was EM gets exhausted and only a restart of the app server clears it (symptoms of memory leak). In that note which I eventually convinced SAP to implement a fix, it focused on users doing a premature termination of the process, leading to EM not released back to pool. So it was a common behaviour then to force restart an app server to reclaim the memory, NOT GOOD.

If you are experiencing memory leaks now then I strongly suggest to patch your kernel. When we applied the Kernel patch, we were originally patch 50... the fix that was included in SAP note brought the patch level to 110 I think. Now a couple of months after the patch level is 200++!!

So basing on the huge increments, I again strongly suggest to get the latest kernel to fix the so many bugs that the old versions have

Cheers

Donald

[Former Member]

Hi Donald,

We are facing this issue since ages and struggling a lot .

Kindly help us out ,how you have resolved the issue..??What was the solution?

Regards

Dedeep

[Former Member]

A Kernel patch fixed our original problem.

Though sadly, it does seem to me that this is a recurring issue. After we patched to a higher patch level, we now get the same or similar symptoms.

We are currently investigating!

And oh, we increased the App Server memory to double its size. As annoyingly enough SAP suggested that our original memory was now too small

[IanSegobio]

Hello Donald,

Whenever dealing with LOAD_NO_ROLL dumps in 74x SAP kernels, you can approach it like a regular TSV_TNEW_PAGE_ALLOC_FAILED dump which is, lack of HEAP or EM during the processing of the request.

Our team created some very nice documentation on that:

Memory Dumps as of Kernel Release 7.4x - Application Server Infrastructure - SCN Wiki

TSV_TNEW_PAGE_ALLOC_FAILED - Application Server Infrastructure - SCN Wiki

Cheers,
Ian Segóbio.

[Former Member]

Thanks Ian, very well written blog!

Yes indeed tuning is key but there were a couple of major issues when I raised this thread:

1. Our system usage stayed the same but since upgrading to the new Kernel, SAP required more memory than before (hence doubling the size of allocated PHYS_MEMSIZE helped). The fact that the memory architecture and allocation has changed increased the chances of the LOAD_NO_ROLL happening. The increased usage is confirmed in this SAP note - unfortunately came out months after we had the problem - so that kept me guessing what the behaviour was of the SAP memory in the new kernel.

Had it been out earlier, that could have save a lot of pains fixing the problem.

SAP Note 2148571 Explanation of higher EM and EG consumption after upgrade to SAP Kernel 7.4x

2. There was in fact a memory leak bug which led SAP to create a SAP note and a fix. The error published in that note was from me / SAP message I sent. The bug goes - if the end user soft-cancels the transaction, it leaves the used EM in a hung/stuck state and not released back to the pool. Hence over time, the EM gets fragmented. Applying the latest kernel with the fix definitely addressed the last remaining issues we have.

NOW more than a year on. We are getting similar issues. Again, no change in system usage. The last change was a kernel patch, so we are following up with SAP to see what this is. There are early indications that our EM got fragmented over time which is a sad reality

[Former Member]

Hi Donald,

I think the discussion is going in the right direction. But SAP has already suggested the solution in their SAP notes. I also think that you can upgrade the kernel to latest Patch releases 742/200 or the newer .

The second improvement I did ,implemented the zero memory as of Kernel 740.  Physical mem.size should be set as your requirement and rest o f the parameter will be calculated automatically. Check SAP notes for that purpose.

Now LOAD No ROLL dump and TSV new page alloc dump you need to tune the system if it is not enough after doing ZAMM.

Thanks

Biswajit

[Former Member]

Hi All,

We have memory leak issues with the early patches of 7.41 which includes your concerned patch. I would suggest you to apply the latest patch available which includes the fixes for such issues.

Also if you want you can check the regression for every kernel patch in xsearch(SMP) with keyword 'KRNL<>PL<>' and in your scenario it should be 'krnl741pl50' or 'krnl741pl100'.

You can refer the below note :

2053503 - Known regressions in kernel 7.41 patch level 50

Hope it helps to get the quick conclusion with the known issues.

Regards,

Omer Bashadi