How to estimate the memory consumption of the Integrated ITS

With the integrated ITS SAP provides a monitor transaction which allows to check the amount of memory currently used by the Integrated ITS. Some issues related to that will be discussed here, especially the estimation of the memory consumption and the consequences for the setting of the system parameters.

The Memory consumption of the Integrated ITS

With the Integrated ITS, SAP provides a monitor transaction (SITSPMON) which allows to check the amount of memory currently used by the Integrated ITS.
This memory consists of two main sections: Memory related to user sessions - we call it 'Session Memory' and memory used without belonging to this sessions 'Work Process Memory'.
The following snapshot of the memory statistic screen will be used for discussing some ITS related memory issues. Please click on the thumbnail below to enlarge the screenshot. Please click on thumbnail image to see full sized image.
The screenshot has been taken from one development system while the user GOMER works on it (as hard as we know him). This engaged user works already with four sessions while the fifth is being created. Not visible on the screenshot: Two ITS services are used, three sessions use the service 'webgui' and the forth session uses the Internet Application Component 'IT00' which provides a template for each screen.

The Session Memory

The session memory - the name implies that already - is used to store session related data. It is not surprising that its amount depends on the transaction and the complexity of the screens used by this session. Large Gridview - or Column Table Controls are good examples for memory consuming screen elements. Some things are noticeable here:

In session 5430 and 5432 the peak value of the memory amount differs from the current memory usage. This two sessions are WEBGUI sessions with more complex screens. For this reason not only the memory usage is larger than for the other session, but also the difference between the peak value and the current one are noticeable. The reason for that is the complexity of the controls used here, we need much more data to be passed while processing the screen data in Business HTML.
Session 5542 processes a dynpro with some simple controls, it is as humble as session 5547 which handles the IT00 service.

The columns 'Total' contains the number of memory allocation calls the session did in the past and the column 'Current' shows the number of memory objects currently in use.

The Work Process Memory

The work process memory is mainly used for storing the processed Bussiness HTML templates in the template cache. This cache must be accessible to every work process, therefore we use a part of the shared memory for it. The amount of memory each work process uses from its private address space using malloc() for ITS data can be neglected. As you can see, the template cache has a size of approximately 4 MBytes. The snapshot below shows the contents of the template cache. Please click on the thumbnail below to enlarge the screenshot. Please click on thumbnail image to see full sized image.
Here we can see that six screens of the service IT00 has been accessed. The first three entries are related to the WEBGUI service which uses the facility of generating dynpro without having a template for each screen.
Another thing what might attract attention is the stability of the amount of used work process memory: The peak value is almost identical to the current memory consumption. This should not change as long as the template cache has not been invalidated. The template cache will be invalidated when a template has been published after being changed (using the transaction SE80). Invalidating means to clear the whole cache independent of the published template(s). The memory usage will then increase which every used template.
In a well designed productive system the size of the template cache will be large enough to hold every template the ITS applications used. Here we do not expect a dramatical change in the memory consumption. The parameter itsp/SAPjulep/MaxHtmlPPs determines the number of templates which can be stored in the cache.

Note.

If you see negative values in the Work Process memory Consumption table, this is not wrong per se. This only means that a particular amount of shared memory was freed by a workprocess other than the workprocess where the memory was allocated.

Memory currently available for the ITS

The ITS uses memory of the extended global memory area (EG) configured using the parameter em/global_area_MB, 64MB in this example. But not only the ITS uses this part of memory. Other components, like ABAP shared objects f.i., do this too. In order to protect the WebAS from running out of memory we introduced a watermark. When the amount of memory used reaches this watermark, further ITS sessions will be refused. The parameter itsp/max_eg_mem_percent determines this limit, it defaults to 80 (or 99 in newer releases). This means that no more ITS logons are possible as long as the amount of free memory is less than 20% (or 1% in newer releases).
In our snapshot we can see, that other WebAS components are using approximately 16.6 MB.

Estimating the Memory requirements

Using our example above we can see, that an average ITS session needs 1 MB of memory while we still have 25 MB available for further sessions. Assuming that no more templates are needed, we estimate the maximal number of concurrent sessions to 30, which is not too bad for my small computer box.
For estimating the maximal number of concurrent ITS sessions in general we must obtain the amount of EG memory used by other components. Unfortunately we can not offer a tool for that, it is highly dependent on the running applications and how much data will be processed there. But here we can offer the transaction SITSPMON for watching the current situation.
With the values displayed there we can calculate the amount of memory used by other components.
It calculates to:

em/global_area_MB * itsp/max_eg_mem_percent / 100 - ITSMemory

Using this value and the data displayed on the memory statistics screen we are able to estimate the possible number of concurrent sessions and to adjust the parameters discussed here.

Page tree

The Memory consumption of the Integrated ITS

The Session Memory

The Work Process Memory

Memory currently available for the ITS

Estimating the Memory requirements

See Also