Registration

Dear SAP Community Member,
In order to fully benefit from what the SAP Community has to offer, please register at:
http://scn.sap.com
Thank you,
The SAP Community team.
Skip to end of metadata
Go to start of metadata

OMS Heap

This page provides background information about the OMS Heap.


What is the OMS heap?
What is the benefit of the OMS heap?
Consistent Views and OMS versions
Which data is located in the OMS heap?
Configuration of the OMS heap
Allocation of heap memory
Current heap usage

See also: OMS Heap, SAP MaxDB Memory Sizing


What is the OMS heap?

Within a transaction the first read of an object will cause the creation of a consistent view.
When data is read for the first time by a database procedure, this data is copied from the data cache to the OMS heap which is a private memory area. All other operations are then performed only on this copy. Only at the end of a transaction, more precisely at the commit, data changes are written back to the data cache. (Transactional simulations also copy data to the heap, however these are not stored in the data cache after the end of the transaction simulation. This means that changes in transactional simulations are not persistent.) Used memory in OMS heap allocated by LCA routines is normally released after the end of the routine but latest at the end of the transaction. The physical memory is not released when this is done but free memory is administered in the so-called free list.

back to top

What is the benefit of the OMS heap?

The OMS heap has been introduced, among other reasons, to improve performance further. Data in the data cache is available for all applications and must be protected against parallel changes using appropriate methods (semaphore). This protection is no longer necessary if the assignment of the data to an APO/SCM application is fixed after the data is copied to the OMS heap. The internal liveCache access strategy for data access is also quicker if the data is maintained in the private heap area. In total, these optimizations mean that a heap access is between two and five times faster than an access to the data cache.

back to top

Consistent Views and OMS versions

An APO/SCM application can create a so-called OMS version (f.e. when transactional simulations are used). Contrary to a Consistent View an OMS version can exist after the end of a transaction and can be used by the APO/SCM application further on. An OMS version may exist far beyond the end of a transaction. Only one transaction can work with the OMS version at the same time. You can get an overview about the currently existing OMS versions in transaction LC10 (Problem analysis -> Performance -> OMS versions) or with the following SQL statement:

SELECT * from oms_versions

Currently existing consistent views are shown by the following statement:

SELECT * from consistentviews

back to top

Which data is located in the OMS heap?

The biggest part of the heap is used by OMS data. Additionally auxiliary structures on the heap are created by the OMS runtime which are used to implement the OMS functionality, e.g. hashes, rollback information, directories.

How much memory is used in the OMS heap depends on how much data is processed within a transaction (i.e. on the size of the consistent view for this transaction) and secondly how much data is used within an OMS version and how much OMS versions are existing simultaneously.

back to top

Configuration of the OMS heap

Unlike the data cache, the size of the OMS heap is not fixed when the liveCache is started. The OMS heap grows dynamically if the existing heap is not sufficient for including additional data copies. You can assign a maximum value for the size of the heap using the liveCache parameter OMS_HEAP_LIMIT. If OMS_HEAP_LIMIT=0, the growth of the heap is unlimited, in theory, until the virtual memory is exhausted. Therefore, restricting the size is absolutely necessary, or even compulsory (see SAP Note 337445).

The OMS-Heap cannot use Microsoft Windows extended memory (AWE).

History data (before images of objects) is located within the data cache to allow consistent read of an OMS version. History dara can only be deleted from data cache if the OMS version is dropped - either by the application itself or by the liveCache reaching the MAX_RETENTION_TIME. Also parameter MIN_RETENTION_TIME influences the life cycle of OMS versions.

Parameter MAX_RETENTION_TIME marks an age limit (in minutes) of active OMS versions identifying when history data of these OMS versions is deleted by the garbage collectors.

If there is an acute bottleneck within the system because the filling level of the data volumes exceeds 90% the parameter MIN_RETENTION_TIME intervenes and triggers the deletion of history data of several OMS versions. MIN_RETENTION_TIME defines the minimal timespan (in minutes) to keep history data.

Data of an OMS version is moved to the data cache if its heap consumption is bigger than defined by the parameter OMS_VERS_THRESHOLD.

OMS versions are moved completely to the data cache if the heap is filled up to OMS_HEAP_THRESHOLD percent. Default for this value is 100%.

See also Heap usage - table "OMS Heap Usage"

back to top

Allocation of heap memory

Memory is allocated by the LVCMem_BlockAllocator little by little in concatenated blocks. The size of these blocks is defined with parameter OMS_HEAP_BLOCKSIZE. If an APO/SCM application needs more memory firstly the heap internal free list is checked. Only if there is no more memory available new memory is allocated by the LVCMem_BlockAllocator. If just a part of the blocksize is necessary the remaining memory (block size - used part) is not released anyway. Only complete blocks can be released - and these are inserted into the free list for further use.

By default the OMS_HEAP_BLOCKSIZE is set to 10000 KB and should not be changed. The block size should not be too big or too small. If available memory on the server is segmented to a high degree and the block size is defined too big, memory allocation might fail even if the overall amount of free memory is still sufficient.

If the block size would be defined too small more often the application will allocate a memory area that is bigger than the block size. In this case the memory will be allocated directly by the RTE-Allocator without checking the free list before. So it may happen, that (if the heap limit is reached) no more memory for an APO/SCM application can be allocated even if there is actually enough memory in the free list. As of version 7.5.00 B31 also the free list is checked if there is enough memory for those memory requests (see PTS 1136206) so it is not a problem any longer.

The allocated memory is used by an OMS_Allocator (in versions <= 7.5.00 B30), several LVCMem_Allocators and one LVCMem_EmergencyAllocator. Depending on the number of CPUs there are several LVCMem_Allocators which means that the heap is divided into sub-heaps and allows a higher parallelism. The number of LVCMem_Allocators is defined by the parameter OMS_HEAP_COUNT (max. 128). If possible, OMS_HEAP_COUNT should have the same value as MAXCPU.

The following statement provides exaxct information about the number of LVCMem_Allocators and use of memory:

select * from oms_heapstatistics

There is a difference between LVCMem_Allocators and the OMS_Allocator: LVCMem_Allocators are used by liveCache applications i.e. LCA routines (e.g. SAPAPO) and the OMS_Allocator is used by the OMS runtime liboms. This classification used to simplify error diagnosis is obsolete as of version 7.5.00 Build 30.

The LVCMem_EmergencyAllocator is activated by the LVCMem_Allocator if the heap limit is reached i.e. if there is no more memory available. This allocator has a reserve of 10 MB to allow the creation of a Bad Alloc Exception which can be thrown to the application. The application should close the session and after the end of the transaction the memory is released. The LVCMem_EmergencyAllocator is exclusively assigned to a task if there is shortage of memory. This task can come to a defined end and even allocate some more memory from the LVCMem_EmergencyAllocator. Afterwards the tasks releases the LVCMem_EmergencyAllocator.

back to top

Current heap usage

You can get information about the current heap usage with transaction LC10:
Current Status -> Memory Areas -> Heap Usage



An important information is the Maximum Heap Usage which should be significantly smaller than the configured maximum OMS_HEAP_LIMIT.

The following statement shows how much memory is provided for the different allocators:

select * from memoryallocatorstatistic

´

Based on the values of column allocated_bytes you can determine more exact values about heap usage. If there is no access via LC10 available the following formula calculates the momentary use of heap memory.

  USED_HEAP = 
  allocated_bytes der LVCMem_Allocators 
+ allocated_bytes des OMS_Allocator 
+ allocated_bytes des LVCMem_EmergencyAllocator  

When USED_Heap is known you can find out how much memory is available within the heap in the free list:

  FREE HEAP =
  allocated_bytes des LVCMem_BlockAllocator 
- USED_HEAP

back to top

Relevant SAP Notes

1128916 FAQ SAP MaxDB/liveCache Heap Management
337445 SAP liveCache and Memory Management