Memory consumption of internal sessions

[andreas_singer]

While analyzing the memory consumption of some reporting transactions (e.g. MB51, SDO1, FBL5N, ...) with transaction SM04 (-> goto Memory -> goto Memory (Session Details) -> goto Memory (I-Session Details)) I found the following behaviour on performing the following steps:

Step 1: Call reporting transaction (for example MB51)

SM04 Memory (I-Session Details) shows the following memory allocation:

int. session 1: MB51 - e.g. 2.500.000 bytes (probably from SAP Easy-Access

menu)

int. session 2: MB51 - e.g. 500.000 bytes (memory requirements of the MB51 selection screen)

Step 2: Perform selection of some data with MB51

SM04 shows the following memory allocation:

int. session 1: MB51 - e.g. 2.500.000 bytes (same as before)

int. session 2: MB51 - e.g. 6.000.000 bytes (memory requirements of the MB51 data)

Step 3: Go back to the MB51 selection screen with the back-button

SM04 shows the following memory allocation:

int. session 1: MB51 - e.g. 2.500.000 bytes (same as before)

int. session 2: MB51 - e.g. 6.000.000 bytes (same as before: memory requirements of the MB51 data from the first selection?)

new int. session 3: MB51 - e.g. 500.000 bytes (new session for the selection screen?)

Step 5: Perform another selection (with same or different selection criteria - it doesn't matter)

SM04 shows the following memory allocation:

int. session 1: MB51 - e.g. 2.500.000 bytes (same as before)

int. session 2: MB51 - e.g. 6.000.000 bytes (same as before: memory requirements of the MB51 data from the first selection?)

int. session 3: MB51 - e.g. 6.000.000 bytes (memory requirements of the MB51 data from the current selection?)

If I repeat the last two steps (go back and reselect) a few more times, the internal session number 3 releases and reallocates its memory depending on the amount of data selected/released. This is the behaviour I expected.

The question is, why the data of the first selection remains in the int. session 2 and still uses the memory there?

Is there any sense in opening a third int. session at step 3 and preserving session 2? Why is the memory of the selected data in session 2 not released when going back to the selection screen. This memory area remains allocated until I leave the transaction and so it may lead to situations where users allocate twice as much memory than they are aware of.

Thanks for any help, hints and explanations!

[Former Member]

You question is very interesting and therefore I thought of replying it.

I am not sure it satisfy your or not, but my analysis as follow.

When first time user logs into the system certain memory is allocated for the user context .This user context is nothing but your user master data including the roles and profiles information.This is probably roll_first that is max 100KB.

So with first session you have occupied some memory.

You have opened internal session and have selected some data .The memory is again allocated to this session from extended memory.

Now your two session may be having data +users information in roll and extended memory .So your initial two seesions can never release memory until your 3rd and 4th session finishes.

Because your 3rd and 4th sessions are not sharing roleextended memory for datauser master records but abolutely independent extended memory block.

So while completing the task and going back to screens release the memory but session 1 and 2 will release memory

after logging off.

Hope it helps.

Amit Asthana

[former_member185954]

Hello Andreas,

Every session would be processed in a seperate dialog process hence every session would require seperate memory.

The reason why it keeps the memory still in the session maybe related to some kind of lazy write process used by SAP kernel to empty unused memory.

Imagine this , if the system was required to quickly release memory once the user is out of the transaction, it would put considerable load on the CPU switch with concurrent users switching between screens.

Regards,

Siddhesh

[andreas_singer]

But this does not explain the behaviour in comparison to int. session 3, where the memory is released immediately when navigating 'back' and no 4th session is openend.