Application Development and Automation Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 
Read only

memory low problem

Former Member
0 Likes
3,670

HI Experts!

in one z program while executing ,its showing message ' memory low' .

its execution time is 30 min. while all other transactions are stopped from executing. i have chech all sql staements for optimization and they a correct . how i can solve this problem .Can i do it in background processing . what will be its benefits .plz help me in this .

thanks .

ranjana

1 ACCEPTED SOLUTION
Read only

Former Member
0 Likes
2,325

Doing it in a background task will help. The DYNPRO work process will always consume more memory.

Please schedule your program some time during the night when no body else uses the system(this will ensure that more memory is available for your job), to schedule jobs use transaction SM37.

8 REPLIES 8
Read only

former_member194152
Contributor
0 Likes
2,325

Hi,

MAy be it is problem of BASIS guy just ask to him for alloted space for program working and database buffer and if huge data is retrived from database to internal table then you have to go for field groups.

Regards

Gagan

Read only

Former Member
0 Likes
2,325

Hi,

Check your internal Table. It may contains huge data's.

Check this,

https://forums.sdn.sap.com/click.jspa?searchID=5506221&messageID=3692745

Thanks,

Reward If Helpful.

Read only

Former Member
0 Likes
2,326

Doing it in a background task will help. The DYNPRO work process will always consume more memory.

Please schedule your program some time during the night when no body else uses the system(this will ensure that more memory is available for your job), to schedule jobs use transaction SM37.

Read only

0 Likes
2,325

"The DYNPRO work process will always consume more memory."

DYNPRO work process... very interesting...

Read only

Former Member
0 Likes
2,325

Hi,

Note 116042 - Message "Memory low."

Symptom

In any transaction, the following message is generated at the bottom of the screen 00072 "Memory low. Leave the transaction before taking a break!").

User and system adminstrators do not know how they should respond to this message.

Additional key words

Message 00072, extended memory, heap memory, PRIV, PRIV mode

Cause and prerequisites

This message is NO error message.

In certain cases, it may point to a performance problem.

The information "Memory low" only refers to ONE memory area of the R/3 System, the extended memory. However, the users can request aditional memory in a different memory area, the heap memory, and can continue to work normally. However, a work process is reserved exclusively for the users who use heap memory for that time (that is known as PRIV mode).

In certain configurations and systems, the use of heap memory is even intended!

The described message is new in Release 4.0 (only the message, the described situation has also already occurred in Release 3). This may be the reason that many users and administrators complain about the "memory errors" and "memory problems" after upgrading to Release 4.0 although objectively no errors can be found.

Solution

What should users and system adminstrators do when they receive this message.

User: -


Users should proceed as proposed in the long text to the message:

"Continue to work as normal and exit the transaction before you take a long break."

System administrators: -


Under certain circumstances the message may point to a performance bottleneck. Therefore system adminstrators should check the following if users report that this message occurred:

1. Call the work process overview (Transaction SM50) and observe this some minutes (pushbutton -> Refresh) - see, whether work processes remain in the state

Status = stopped and Reason = PRIV,

Status = running and Action = roll in

Status = running and Action = roll out

If you find more than 50% of the work processes in this status, then there may be a problem in the configuration.

If you find less than 50% of the work processes in this status, no problem exists.

2. Call Transaction ST02.

Check the field "Extended memory" in section "SAP memory", "Current use %". This indicates the current consumption of extended memory.

If this value is > 90%, a problem may exist in memory configuration.

If this value is < 90% is, no problem exists.

What needs to be done?

If you find that extended memory is configured too small, then you should increase it.

It may also be necessary to increase the number of work processes.

Regards,

Padmam.

Read only

Former Member
0 Likes
2,325

Hey, the memory your internal table is using is overflowing, normally 2 gb of memory space is provided for a program, maybe ur Internal Tables are eating up all the memory

Try to reduce unwanted fields of your internal table by removing them.

Try to provide more parameters in the WHERE clause of your SELECT queries so that only relevant data comes to your internal tables.

Try to delete the tables using REFRESH statement if the data is not required in the forthcoming part of code.

So just check the code and see what you can do.

Reward points if useful, get back in case of query...

Cheers!!!

Read only

Former Member
0 Likes
2,325

Hi,

try the following 2 steps i also had the same proble by using following 2 methods i got solution

1. Try to refresh internal tables after consuming data from that

2. if its possible use package size in ur select query

Message was edited by:

Manikumar shanmugam

Read only

Former Member
0 Likes
2,325

Hi Ranjna,

This is not bcz of performance issues. The MEMORY BUFFER allocated to SAP R/3 is being utilized heavily by your program. What it means is, you program is retrieving huge amount of data.

1. Either filter the no. of records processesed by reducing the selection criteria.

2. Else ask the BASIS guy to increase the memory. Simply tell him the dump & he would fix it.

Best regards,

Prashant