SAP Netweaver Business Warehouse (SAP-BW) system is fundamentally mainframe technology wrapped in modern day client server architecture. This places a multi-disciplinary requirement on those who configure and use the run-time environment. The reporting user community is the only group who does not need to know about the run-time environment in detail; they just want their reports to run as fast as possible.
Keep reading if you do more than just run the BW queries.
In the spirit of mainframe fundamentals, the execution of most BW programs involves a ‘process’ that runs on the application server. There are a limited number of process slots available. Each has a dedicated amount of resources available for it to achieve the program objective. The primary hardware resource used by a process is computer memory (aka RAM).
While its use has been optimised to included features like private mode, shared memory and caching at different levels of hardware and software abstraction; there is still only a fixed amount of memory available for the whole system to use. This is where the mainframe aspect is an advantage because it reduces the risk of server freezes.
Keep in mind that a typical server will be running the following software:
- Operating system;
- Database service;
- SAP Netweaver Kernel;
- Additional SAP Applications;
- Other corporate software.
The operating system is primarily responsible for finding a practical balance between these running applications. When the demand of the applications exceeds the amount of physical memory then the operating system starts to utilise virtual memory (aka swap memory). This is where the operating system utilises the hard drive space to store the memory content.
This memory effectively goes off-line. It is not directly accessible by any running programs until it has been restored from the hard drive back into physical memory. As far as the running application is concerned, the memory was always there and available.
What the running application failed to notice was that it went to sleep while it waited for the virtual memory to be restored back into physical memory. It is like going to sleep at night and not remembering your dreams; you closed your eyes for just a second and it is already the morning, time to get up and keep going.
The noticeable aspect of virtual memory is that a running application would seem to have slowed right down. It has not crashed but it can seem like someone is leaning against a [Go Slow] button. What should have taken the blink of an eye, now takes a couple of seconds.
“the applications effectively slow down to the
speed of the hard drive input/output (IO) capability”
When you load too many applications on a server, beyond the practical balance point of physical memory usage, there is a significant decrease in real application output as the hardware is spending more and more time doing memory management.
Running programs on the ABAP stack in the SAP Netweaver kernel has several configurable memory options:
- Number of process slots;
- Initial memory used by a process slot;
- Max physical memory expansion;
- Max virtual memory expansion.
A fresh installation of the SAP Netweaver kernel will have a number of process slots pre-configured for the system to be able to work. This default configuration is not optimised to the server it is running on.
A basis team member should be given the task to evaluate and adjust the process slot configuration. This would have involved careful consideration of the other running applications and the amount of memory the SAP Netweaver kernel would be demanding from the operating system.
At this point in time the basis person is only considering the practical balance of multiple applications sharing the physical memory. There would have been no consultation with the BW administrator who is responsible for the execution of process chains and probably has a Service Level Agreement (SLA) for the completion of the nightly load window.
There are strategies and techniques that can be implemented in the process chains to enable effective use of the process slots. This provides a solid approach to discussing the available processes with the basis team while allowing for their often absolute and hard line answers like “I can’t give you memory that is not there; not without slowing the whole server down”.
What do I take into consideration when balancing the memory requirements for the operating system?