Application Development 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: 

Do itabs in ABAP program memory swap out when the program is swapped out?

Former Member
0 Kudos
99

Do itabs in ABAP program memory swap out when the program is swapped out by the app server scheduler?

If so, has anyone compared the time it takes to open/close an Oracle table n times with the time it takes to swap an itab of 50M in and out n times?

1 ACCEPTED SOLUTION

Former Member
0 Kudos
78

Hi David,

yes, the memory is alloted per instance of the call of the code, the memory is made free after.

As for comparing the actual time I agree with Andrew that you have to consult your App Server Scheduler.

Maybe running the transaction SE30 - Tips and Tricks will more or less give you an idea on the time it takes.

- charles -

4 REPLIES 4

Former Member
0 Kudos
78

David,

Don't know the answer to your question, but would ask is it the App Server Scheduler that would handle this, or is it the operating system. As each ABAP work process is separate at the OS level you should be able to view using Task Manager (assuming Windows) or equivalent in other OS and see the stats for paging etc.

I suspect that while the process will be swapped in/out of execution, the physical paging of the internal table from memory to disk will be controlled by other requirements such as what else is running that requires the memory, and also by ageing factors such as when was it last referenced. (I am sure it is actually a lot more complicated than this).

If the memory is not over-written, then processing of the internal table should continue at a higher speed than a re-read from the database will. Given modern memory is in the multi-GB range, an internal table of only 50MB should not be swapped much, if at all.

Andrew

0 Kudos
78

Andrew -

Although your suspicion appears to be wrong (according to the answer provided by CharlesF below), I'm awarding 6 because your answer indicates that you are at least sensitive to the issues involved here (which is better than 90% of the SAP practitioners out there.)

However, I do want to take strong issue with you on the matter of how much available "multi-gig" memory is available, because this is irrelevant to the issue at hand.

The question is: how does the swapin/out of large program memory affect the scheduler on the app server?

This is a queueing theory issue that has nothing to do with how much memory is out there.

Back in the days when folks had to know a little queueing theory (to evaluate the pro's and cons of ISO vs SNA and token-ring vs other protocols, everyone understood that if you ask the scheduler to repeatedly swap "alot" and to do so very often, then there will be a profound ripple effect on system performance, not just for anyone "job" or "program", but for any and every job or program.

The reason is very simple, and the folks who taught the ISO/SNA seminars always used it: traffic flow on passenger highways is always best when there are few trucks travelling with the cars. This is why the New Jersey turnpike sometimes splits into two "cars only" and "trucks and cars" highways, and why many other roads have "right lane" only restrictions for trucks in certain areas that tend to get congested ...

Anyway, always a pleasure to chat with you ...

Best regards

djh

Former Member
0 Kudos
79

Hi David,

yes, the memory is alloted per instance of the call of the code, the memory is made free after.

As for comparing the actual time I agree with Andrew that you have to consult your App Server Scheduler.

Maybe running the transaction SE30 - Tips and Tricks will more or less give you an idea on the time it takes.

- charles -

0 Kudos
78

Hi Charles -

Since you phrased your answer authoritatively, I will assume it's correct. (Of course, I also want to assume it's correct because it helps me make the point I wanted to make in this thread.)

Thanks very much for taking the time to reply.

Best regards

djh