2008 Mar 27 7:07 PM
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?
2008 Mar 28 3:32 AM
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 -
2008 Mar 28 2:15 AM
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
2008 Mar 28 2:21 PM
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
2008 Mar 28 3:32 AM
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 -
2008 Mar 28 2:25 PM
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