cancel
Showing results for 
Search instead for 
Did you mean: 

Memory consumption / allocation / deallocation

0 Kudos

Hello all,

we have an application with (to simplify matters) two views (search and data-display).

The search-view triggers a search method within the component controller, populates the context and finally the result-view will be called. An ALV is used to display the results.

Unlikely we are working with very huge data amounts (1 row has approx. 8000 chars in 140 fields) and we are receiving up to 50.000 lines. The business guys need all of them, as you may know ....

The memory consumption (via SE04) for this kind of result is somehow around 1.4 GB (!!!) - this would be acceptable. But after navigating back and re-executing te same (or similar) search the memory usage grows to higher values between 1.7 and 2.2 GB. Each further re-execution increases the memory usage (by approx. 200 MB) until an out of memory error occurs.

We tried to force a deallocation of memory by invalidating the context nodes after leaving the result view (this will deallocate up to 10, maybe 20 MB).

Freeing the ALV component usage (usage->delete_component( ) and free reference ) has no noticeable effect.

Is there another way to deallocate the memory?

If I start the application a second time within the portal, it has no effect (all the memory is still allocated); only a refresh (F5) in the browser will free the memory.

I thought about moving the result to a second component and to embed it via a component usage - but I expect the same result as freeing the ALV usage.

Any ideas out there ?

Best regards

Waldemar

Accepted Solutions (0)

Answers (2)

Answers (2)

Former Member
0 Kudos

Hi!

This may have several reasons.

Have you tried transaction SE30 to find out the memory consumption root cause?

Maybe you still hold references to large objects you do not need anymore and therefore the garbage collector cannot do his job?

Are you sure that your internal tables used in you business logic are cleared when the data are not needed anymore.

Sometimes always an APPEND is used and the internal table grows and grows ...

If that does not help force a runtime error (e.g. by MESSAGE X....) and then have a look at transaction ST22. Maybe you will find the object or internal table consuming the memory.

Regards,

Volker

S-H
Active Participant
0 Kudos

Hi Waldemar,

ALV takes more time(w.r.t performance) than table, if you have huge number of records then you can use Table instead of ALV.

Best regards,

Suresh