SAP NOTE 1999997 - FAQ: SAP HANA Memory

Make sure that house-keeping is set up for technical, administration and communication tables so that they don't consume unnecessary memory.

See SAP Note 2388483 for more information.

Implement archiving strategies for business data.

Have a look at the Information Lifecycle Management area for more details.

S/4HANA significantly reduces redundancy of table data (e.g. FI: elimination of BSEG index tables like BSIS, BSID, BSAS and BSAD) and so it has a positive impact on the memory footprint. See the Simplification List for S/4HANA for further details.

Hybrid LOBs are not loaded into memory when the size exceeds a defined limit, so it is usually beneficial for memory consumption if you take advantage of this feature.

SAP Note 1994962 describes how columns defined as memory LOBs can be converted to hybrid LOBs.

SAP ABAP table columns with LRAW data type are mapped to either LOB or VARBINARY. As VARBINARY always has to be loaded into memory, this can have an effect on the memory utilization. See SAP Note 2220627 ("Is VARBINARY also a LOB Type?") for more information.

SAP Note 2375917 describes how a VARBINARY column can be converted into a LOB in order to save memory.

Check for indexes with high memory requirements (e.g. using SQL: "HANA_Indexes_Overview", ORDER_BY = 'SIZE' from SAP Note 1969700) and check if you can drop some of these indexes. A focus can be put in the following areas:

• Secondary indexes that were created in order to optimize the performance of non-HANA databases.
• BW: If DSOs are changed from "standard" to "write-optimized", a primary index is no longer required.
• BW: Check if you can flag the property “Allow duplicate records” of write-optimized DSOs because this will eliminate the need for multicolumn key indexes (/BIC/A…00KE).
• Check if large fulltext indexes are really required. For example, a large index REPOSRC~SRC (on a column with name $_SYS_SHADOW_DATA) may exist to support the ABAP Sourcecode Search (SAP Note 1918229) and can be removed via transaction SFW5.

Dropping indexes can significantly impact performance, so you should test the effects carefully before permanently dropping indexes.

Multi-column indexes require much more memory than single-column indexes, because an additional internal column (concat attribute) needs to be created.

Check for indexes with high memory requirements (e.g. using SQL: "HANA_Indexes_Overview", ORDER_BY = 'SIZE' from SAP Note 1969700) and check if you can redefine some multi-column indexes to single-column indexes. Often it is a good compromise to define an index only on the most selective column. Further columns like MANDT would significantly increase the memory requirements.

Concat attributes are specific internal columns that can be created for various reasons. Some of them may no longer be required.

See SAP Note 1986747 for more information.

You can run SQL: "HANA_Indexes_ColumnStore_RedundantConcatAttributes" (SAP Note 1969700) in order to define redundant concat attributes - i.e. multiple concat attributes created on the identical set of columns (with the identical order) and use the generated DROP_COMMAND to drop one of these duplicates. A typical reason for this behavior for SID tables in BW environments is described in SAP Note 2376550

Paged attributes are columns that can be loaded into the memory piece-wise. All columns apart from primary key and internal columns can be defined as paged attributes.

For more details see SAP Note 1871386.

As of SAP HANA 1.0 SPS 09 you can reduce the size of multi-column indexes using the inverted hash feature. This can reduce the size of the internal concat attribute that is required for multi-column indexes. See SAP Note 2109355 for more information.

Starting with SAP HANA 2.0 SPS 03 primary keys and unique indexes can be defined as inverted individual indexes which eliminate the need to have a potentially large concat attribute and so the index size can be significantly reduced. See SAP Note 2600076 for more details.

Table data is compressed efficiently in column store, so moving tables from row store to column store usually reduced the memory allocation significantly. Furthermore table columns are only loaded into the column store memory if required and not during startup.

Therefore you can check if large tables exist in row store that can be moved to column store. Be aware that tables with a significant amount of modifications can suffer from performance regressions if they are moved to column store. In case of SAP standard tables you should usually double-check with SAP if the move to the column store is an option.

Some heap areas may be larger than required, e.g. due to bugs or inadequate configuration. See question "What can I do if a certain heap allocator is unusually large?" below for more details.

SQL statements processing large amounts of data or accessing data inefficiently can be responsible for a significant memory growth.

See SAP Note 2000002 related to SQL statement optimization.

See question "Which general optimizations exist for reducing the SQL statement memory requirements?" below for more information.

Long running transactions or idle cursors can impact the garbage collection and result in a high amount of versions or histories.

See SAP Note 2169283 for more information about symptoms, analysis steps and resolutions in the area of garbage collection.

Fragmentation effects can result in an unnecessary row store size.

See SAP Note 1813245 for more information on checking the row store fragmentation and reorganizing the row store.

Starting with SAP HANA 2.0 SPS 04 the row store is defragmented online and automatically once a certain fragmentation level is reached (SAP Note 2789255).

See "Can there be fragmentation in the heap memory?" in order to check if there is an unusual high and recurring fragmentation of the heap memory.

Many records in the delta storage of tables can increase the size of the column store. See SAP Note 2057046 and make sure that delta merges are running properly.

Delta merges (SAP Note 2057046) and optimize compression runs (SAP Note 2112604) temporary require a much larger memory footprint, typically you have to expect that the double size of the underlying table (partition) is needed. Therefore you have to make sure that the size of the table (partitions) is sufficiently small that doubling it is possible without running into a memory bottleneck. Typically you can achieve this by proper data management (see SAP Note 2388483) and by partitioning particularly large tables (SAP Note 2044468).

See SAP Note 2112604 and make sure that the column store tables are compressed optimally.

It is possible to influence the unload behavior so that less critical objects are unloaded first ("UNLOAD PRIORITY <level>" setting for tables) .

The following parameter controls the minimum size of the SAP HANA resource container that needs to be retained (SAP Note 1993128):

indexserver.ini -> [memoryobjects] -> unload_lower_bound

If this size has reached the defined limit and more memory outside of the resource container is required (e.g. because of an expensive SQL statement), an out-of-memory situation is issued. It is usually not required to configure this parameter because the statement memory limit has similar effects.

Data aging (SAP Note 2416490) allows to load only current data into memory while older data is kept on disk. This feature is only available for a defined set of tables.

Using dynamic tiering you can mark data as hot, warm and cold. Typically only hot data resides in the SAP HANA memory. See SAP Note 2140959 for more information related to dynamic tiering.

Based on smart data access SAP HANA can retrieve data from tables in external databases (e.g. Sybase, Oracle or SAP HANA). This reduced the need to load all accessed data into SAP HANA. See SAP Note 2180119 for more information regarding smart data access.

Starting with SAP HANA 1.00 SPS 12 and 2.00 SPS 01 it is possible to configure extension nodes for tables containing no hot data. By overloading the extension node it is possible to share a limited amount of memory by a high amount of tables. See SAP Note 2415279 for more information.

If some hosts in a scale-out scenario suffer from a high memory consumption you can re-locate tables or table partitions from hosts with a high memory consumption to hosts with a lower memory consumption. See section "Table Distribution in SAP HANA" of the SAP HANA Administration Guide for more information.

The following parameter defines the maximum overall memory size which can be allocated by the SAP HANA instance:

global.ini ->  [memorymanager] -> global_allocation_limit

The default value depends on the available physical memory and the SAP HANA revision level:

• SPS 06 and below: 90 % of physical memory
• SPS 07 and higher: 90 % of first 64 GB, 97 % of remaining physical memory

Particularly on SPS 06 and below and hosts with a lot of memory this can result in a significant amount of unused memory (e.g. SPS 06, 1 TB memory, 90 % allocation limit, up to 900 GB allocated by SAP HANA, 10 GB allocated by OS and other components -> 90 GB unused). If you observe a significant amount of permanently unused memory you can increase the global_allocation_limit parameter (e.g. to "95%" or "97%" for SPS 06 and below). Make sure that you don't increase the allocation limit to a value that results in paging.

If multiple SAP HANA instances run on the same host, you have to make sure that the sum of all configured global allocation limits doesn't exceed the available memory.

Make sure that the operating system configuration is in line with the SAP recommendations. See SAP Note 2000003 ("How can the configuration and performance of the SAP HANA hardware, firmware and operating system be checked?") for more information. It is particularly important that the ulimit package isn't installed in SLES environments, because it may define address space limitations (e.g. SOFTVIRTUALLIMIT < 100 % in /etc/sysconfig/ulimit). The following command should return nothing, otherwise it has to be uninstalled:

rpm -qa | grep ulimit 

Make sure that no address space limitations are defined for the SAP HANA processes. You can use the following commands to determine the process ID of the indexserver via ps (<indexserver_pid>) and subsequently check for the configured address space limitations:

ps -ef | grep indexserver
egrep 'Soft|space' /proc/<indexserver_pid>/limits

The correct output without limitation looks similar like the following example:

Limit                     Soft Limit           Hard Limit           Units
Max address space         unlimited            unlimited            bytes

See also SAP Note 1980196 that discusses OOM errors due to an inadequate setting of the Linux parameter /proc/sys/vm/max_map_count.

If multiple SAP HANA instances (or other applications with high memory requirements) run on the same node, make sure that the overall assigned memory (e.g. the global allocation limits for the SAP HANA instances) doesn't exceed the available physical memory.

See SAP Note 2123782 which suggests a pagepool size reduction from 16 GB to 4 GB in Lenovo / GPFS environments.

Make sure that the limit for stack is not set to a high / unlimited value (SAP Note 2488924) as it can result in a significant address space consumption.

If the operating system issues on OOM although there is sufficient memory available, an erroneous strict NUMA memory binding of SAP HANA processes can be responsible. See SAP Note 2358255 for details. This issue is fixed with Rev. 122.02. See SAP Note 2470289 for more information related to NUMA in SAP HANA environments.

The memory allocation of certain heap areas is SAP HANA patch level dependent. Newer revision levels may include optimizations that reduce the memory allocation. Therefore it is generally useful to make sure that a reasonably new revision level is implemented.

Using fewer hosts with a larger amount of physical memory each will reduce the risk that specific SQL statements with a high memory requirement will result in OOM situations, because there is a larger amount of available memory on each host. So for example 2 hosts with 1 TB memory each would have a lower risk of OOM situations compared to 8 hosts with 256 GB each.

See SAP Note 2147247 (-> "How can the memory requirements of the statistics server be minimized?") for details.

If you face a high memory consumption related to DTP activities in BW, you can check SAP Note 2230080 for possible optimizations.

Make sure that you are on reasonably new SAP HANA Revision levels and avoid situations that can cause memory related issues due to SAP HANA bugs. Particularly consider the following scenarios:

Failed to allocate 3098286339661321 byte.

See also "Is the SAP HANA memory information always correct?" -> M_CONTEXT_MEMORY below for scenarios where a wrong implicit memory booking can result in unjustified OOM terminations.

If all above checks didn't help to reduce the OOM situations you should double-check the SAP HANA sizing. See SAP Note 2000003 ("What has to be considered for sizing SAP HANA?") for more information.

M_EXPENSIVE_STATEMENTS

MEMORY_SIZE

M_ACTIVE_STATEMENTS
M_PREPARED_STATEMENTS

ALLOCATED_MEMORY_SIZE
USED_MEMORY_SIZE
AVG_EXECUTION_MEMORY_SIZE
MAX_EXECUTION_MEMORY_SIZE
MIN_EXECUTION_MEMORY_SIZE
TOTAL_EXECUTION_MEMORY_SIZE

M_CONNECTION_STATISTICS
M_SQL_PLAN_CACHE

AVG_EXECUTION_MEMORY_SIZE
MAX_EXECUTION_MEMORY_SIZE
MIN_EXECUTION_MEMORY_SIZE
TOTAL_EXECUTION_MEMORY_SIZE

This allocator is required to keep track of the minimum read timestamp of a SAP HANA instance that is required for garbage collection purposes (SAP Note 2169283). It is an ordered list of read timestamps and the oldest part will be purged as soon as it is no longer referenced, i.e. garbage collection is no longer blocked by a SQL statement / cursor. Significant growth can happen in case garbage collection is blocked for a longer time.

The size of this allocator never reduces unless SAP HANA is restarted.

This allocator contains information for managing the SAP HANA memory. Normally no optimization is necessary. A high memory utilization or frequent memory defragmentations in the system can result in the allocation of smaller memory chunks, which will result in a larger allocator. In this case you should consider the following optimizations:

• Avoid manual memory defragmentations (hdbcons 'mm gc -f', gc_unused_memory_threshold_* parameters)
• Avoid resource container shrinks (hdbcons 'resman shrink', unload_upper_bound parameter) or make sure that reasonable (not too small) thresholds) are used.
• Avoid manual reductions of parameters async_free_target and async_free_threshold (SAP Note 2169283).
• Analyze and optimize the general memory situation (e.g. in terms of data volume, memory leaks, intermediate results) in order to reduce the amount of implicit memory defragmentations or resource container shrinks.

If you experience a very high (and possibly rising) memory consumption due to this allocator, you can determine details with the following hdbcons commands (SAP Note 2222218):

• SAP HANA 1.0: mm level2map
• SAP HANA >= 2.0: mm pagetable

Large sizes of this allocator can indicate the risk of running into address space limitations. 1 GB of allocator size represents around 170 GB of address space. See "Which indications exist that an OOM situation is triggered by the operating system?" below for more details. SAP HANA will run into address space related OOM situations at latest when the following limits are reached:

With SAP HANA >= 1.00.122.16, >= 2.00.012.04 and >= 2.00.023 the growth can be reduced by reducing the minimum size of allocations that are directly requested from the operating system, e.g. to 32 MB:

global.ini -> [memorymanager] -> min_segment_size = 32

Only powers of 2 must be used (i.e. 4, 8, 16, 32, 64, 128, ...), other values can result in indexserver crashes (SAP Note 2731521). Values below 4 (MB) must not be configured. Smaller values can increase the overhead when releasing / requesting memory from the operating system, so you should monitor for potential negative side effects. The currently used limit can be determined via M_SERVICE_MEMORY.MIN_SEGMENT_LIMIT (SAP HANA >= 2.00.040). In the future SAP HANA will internally reduce min_segment_size when a significant amount of the address space is already consumed.

Starting with SAP HANA 2.0 the memory management is optimized and particularly large sizes of this allocators are less likely.

The size of this allocator never reduces unless SAP HANA is restarted.

This heap allocator is used by the Smart Data Quality (SDQ) adapter operation cache. See SAP Note 2502256 for more information about SAP HANA caches in general and the adapter operation cache in particular. The cache can be disabled via:

scriptserver.ini -> [adapter_operation_cache] -> enable_adapter_operation_cache = no

Starting with SAP HANA 2.0 SPS 03 the cache can be cleared using the following command:

ALTER SYSTEM CLEAR CACHE ('AdapterOperationsCache')

This allocator is used in context of parsing (SAP Note 2124112) in order to store internal objects like tables or indexes during preprocessing. Large sizes typically have the same reasons like for allocator Pool/SQLParserGlobal/SQLParserParse. Check the Pool/SQLParserGlobal/SQLParserParse section for possible root causes and solutions.

This allocator stores auditing related information (SAP Note 2159014). In case of large and rising sizes you can consider to disable auditing as a temporary workaround.

SAP HANA 1.00.122.13 - 1.00.122.14 may show an increased size of this allocator. This problem is fixed with SAP HANA >= 1.00.122.15.

If you don't use auditing policies you should make sure that the following SAP HANA parameter isn't set to true, because as long as this parameter is active, memory and CPU overhead due to auditing is possible even if finally nothing is audited:

global.ini -> [auditing configuration] -> global_auditing_state

This allocator is used during conversions of infocubes to HANA optimized cubes using BW_CONVERT_CLASSIC_TO_IMO_CUBE. This procedure is executed when a classic infocube is converted to an in-memory optimized infocube using transaction RSMIGRHANADB. Increased memory consumption is normal when large infocubes are converted. After the conversion of the existing infocubes is finished, executing this procedure is no longer required and the allocator size reduces.

See SAP Note 2057046 and make sure that delta merges are properly configured and executed, so that the delta storage size of the tables remains on acceptable levels.

Pool/AttributeEngine
Pool/AttributeEngine/idattribute
Pool/AttributeEngine-IndexVector-BlockIndex
Pool/AttributeEngine-IndexVector-BTreeIndex
Pool/AttributeEngine-IndexVector-Single
Pool/AttributeEngine-IndexVector-SingleIndex
Pool/AttributeEngine-IndexVector-Sp-Cluster
Pool/AttributeEngine-IndexVector-Sp-Indirect
Pool/AttributeEngine-IndexVector-Sp-Prefix
Pool/AttributeEngine-IndexVector-Sp-Rle
Pool/AttributeEngine-IndexVector-Sp-Sparse
Pool/ColumnStore/Main/Dictionary/RoDict
Pool/ColumnStoreTables/Main/Compressed/Cluster
Pool/ColumnStoreTables/Main/Compressed/Indirect
Pool/ColumnStoreTables/Main/Compressed/Prefix
Pool/ColumnStoreTables/Main/Compressed/Rle
Pool/ColumnStoreTables/Main/Compressed/Sparse
Pool/ColumnStoreTables/Main/Dictionary/RoDict
Pool/ColumnStoreTables/Main/Dictionary/ValueDict
Pool/ColumnStoreTables/Main/Index/Block
Pool/ColumnStoreTables/Main/Index/Single
Pool/ColumnStoreTables/Main/PagedUncompressed
Pool/ColumnStoreTables/Main/Rowid
Pool/ColumnStoreTables/Main/Text/DocObjects
Pool/ColumnStoreTables/Main/Uncompressed
Pool/NameIdMapping/RoDict

Pool/ColumnStore/Main/Rowid/build-reverse-index
Pool/ColumnStoreTables/Main/Rowid/build-reverse-index

Pool/AttributeEngine/Transient
Pool/AttributeEngine/Transient/updateContainerConcat

These allocators contain temporary column store data.

They can grow significantly in case of index creation (SAP Note 2160391). The behavior is improved with with SAP HANA 1.00.122.11 SAP HANA 2.0.

As a workaround you can consider creating indexes at a time when the underlying tables are empty or filled to a minor extent.

Pool/BackupRecoveryAllocator

This allocator stores information required for backup and recovery. A large backup catalog size can be responsible for an increased allocator size (SAP Note 2667371).

Can be linked to problems with garbage collection in column store, see "Which options exist to reduce the risk of SAP HANA memory issues?" -> "Transactional problems" for details.

This allocator is used during conversions of infocubes to HANA optimized cubes using BW_CONVERT_CLASSIC_TO_IMO_CUBE. This procedure is executed when a classic infocube is converted to an in-memory optimized infocube using transaction RSMIGRHANADB. Increased memory consumption is normal when large infocubes are converted. After the conversion of the existing infocubes is finished, executing this procedure is no longer required and the allocator size reduces.

This heap allocator is used for the column store statistics cache (SAP Note 2502256).

Starting with SAP HANA 2.0 SPS 03 the cache can be cleared using the following command:

ALTER SYSTEM CLEAR CACHE ('CS_StatisticsCache')

This heap allocator is used for the data adviser statistics cache (SAP Note 2502256).

Starting with SAP HANA 2.0 SPS 03 the cache can be cleared using the following command:

ALTER SYSTEM CLEAR CACHE ('DataStatisticsAdviserCache')

This cache stores cache invalidation data related to transactions. It can grow when garbage collection is blocked (SAP Note 2169283) or when a high amount of active transactions or holdable cursors exist.

This heap allocator contains different calculation engine object structures, so most of M_CE_CALCSCENARIOS.MEMORY_SIZE is booked there. In addition it is also a parent allocator for calculation engine query plans.

Pool/ChannelUtils/SynchronousPoolCopyHandler

This allocator is used in of backup and restore. The allocated size is linked to the buffer size and the I/O stream parallelism:

Number of parallel I/O streams (default: 1):

global.ini -> [backup] -> parallel_data_backup_backint_channels

Buffer size (default: 512 MB):

global.ini -> [backup] -> data_backup_buffer_size

The following rules for the allocator size apply (with #services = number of SAP HANA services that are backed up):

• File backup: 2 * data_backup_buffer_size * #services
• Backint backup: (1 + parallel_data_backup_backint_channels) * data_backup_buffer_size * #services

Attention: Reducing the buffer size can have a negative impact on backup runtimes.

Pool/AttributeEngine/Delta
Pool/ColumnStore/Delta
Pool/ColumnStoreTables/Delta

Unlike other Pool/.../Delta* areas this allocator stores actual delta related data only to a small extent. Instead it can grow massively during ongoing changes, e.g. mass UPDATEs, so it can be considered more as an "intermediate result set" allocator. In order to reduce the memory footprint you should reduce the amount of records that are modified with a single modification command.

A bug with SAP HANA <= 1.00.122.22, <= 2.00.024.07 and <= 2.00.035 can result in an unnecessary increase of these allocators during UPDATE operations without chunk-wise data processing.

Pool/AttributeEngine/Delta/BtreeDictionary
Pool/AttributeEngine/Delta/Cache
Pool/AttributeEngine/Delta/InternalNodes
Pool/AttributeEngine/Delta/LeafNodes
Pool/ColumnStore/Delta/BtreeDictionary
Pool/ColumnStore/Delta/Btreeindex
Pool/ColumnStore/Delta/Cache
Pool/ColumnStore/Delta/InternalNodes
Pool/ColumnStore/Delta/LeafNodes
Pool/ColumnStoreTables/Delta/BtreeDictionary
Pool/ColumnStoreTables/Delta/Btreeindex
Pool/ColumnStoreTables/Delta/Cache
Pool/ColumnStoreTables/Delta/InternalNodes
Pool/ColumnStoreTables/Delta/LeafNodes

See SAP Note 2057046 and make sure that delta merges are properly configured and executed, so that the delta storage size of the tables remains on acceptable levels.

Pool/AttributeEngine
Pool/AttributeEngine/idattribute
Pool/AttributeEngine-IndexVector-BlockIndex
Pool/AttributeEngine-IndexVector-BTreeIndex
Pool/AttributeEngine-IndexVector-Single
Pool/AttributeEngine-IndexVector-SingleIndex
Pool/AttributeEngine-IndexVector-Sp-Cluster
Pool/AttributeEngine-IndexVector-Sp-Indirect
Pool/AttributeEngine-IndexVector-Sp-Prefix
Pool/AttributeEngine-IndexVector-Sp-Rle
Pool/AttributeEngine-IndexVector-Sp-Sparse
Pool/ColumnStore/Main/Compressed/Cluster
Pool/ColumnStore/Main/Compressed/Indirect
Pool/ColumnStore/Main/Compressed/Prefix
Pool/ColumnStore/Main/Compressed/Rle
Pool/ColumnStore/Main/Compressed/Sparse
Pool/ColumnStore/Main/Dictionary/RoDict
Pool/ColumnStore/Main/Dictionary/ValueDict
Pool/ColumnStore/Main/Index/Block
Pool/ColumnStore/Main/Index/Single
Pool/ColumnStore/Main/PagedUncompressed
Pool/ColumnStore/Main/Rowid
Pool/ColumnStore/Main/Text/DocObjects
Pool/ColumnStore/Main/Uncompressed
Pool/ColumnStoreTables/Main/Compressed/Cluster
Pool/ColumnStoreTables/Main/Compressed/Indirect
Pool/ColumnStoreTables/Main/Compressed/Prefix
Pool/ColumnStoreTables/Main/Compressed/Rle
Pool/ColumnStoreTables/Main/Compressed/Sparse
Pool/ColumnStoreTables/Main/Dictionary/RoDict
Pool/ColumnStoreTables/Main/Dictionary/ValueDict
Pool/ColumnStoreTables/Main/Index/Block
Pool/ColumnStoreTables/Main/Index/Single
Pool/ColumnStoreTables/Main/PagedUncompressed
Pool/ColumnStoreTables/Main/Rowid
Pool/ColumnStoreTables/Main/Text/DocObjects
Pool/ColumnStoreTables/Main/Uncompressed
Pool/NameIdMapping/RoDict

These allocators are responsible for parts of the main storage in column store. Their memory allocation will implicitly reduce if you reduce the amount of table data in column store (archiving, cleanup, reduction of indexes, ...)

Pool/ColumnStore/System

This allocator contains column store metadata and its size mainly depends on the number of column store tables and columns. Sizes up to 10 GB are normal for systems with 100,000 to 150,000 tables. If many small tables exist, the relative allocator size can be significant compared to the actual table sizes. This is expected and doesn't indicate an issue.

This allocator can grow in case a large number of network channels exist (due to inter-node or inter-service communication), see SAP Note 2222200 for more information related to SAP HANA network.

A memory leak issue was fixed with SAP HANA 1.00.122.05.

Another memory leak is fixed with SAP HANA 2.00.021.

This heap allocator stores information related to SAP HANA contexts. An increased size indicates the existence of a high number of contexts. For more analysis steps see the context related information for heap allocator Pool/Statistics.

This allocator can grow with SAP HANA 2.00.020 and 2.00.021 due to a memory leak related to hash functions (e.g. HASH_SHA256). You need to restart SAP HANA in order to reclaim the allocated memory.

The related call stack module (that can be checked via an hdbcons allocator block list as described in SAP Note 2222218) is Crypto::Provider::CommonCryptoProvider::initHash.

This heap allocator is used for the Native Storage Extension (NSE) buffer cache (SAP Notes 2502256, 2799997). The size can be controlled with the following parameters:

indexserver.ini -> [buffer_cache_cs] -> max_size = <max_size_in_MB>






indexserver.ini -> [buffer_cache_cs] -> max_size_rel = <max_percent_of_memory>

See question "Which general optimizations exist for reducing the SQL statement memory requirements?" below in order to make sure that SQL statements are executed as memory-efficient as possible.

This allocator is used during plan execution of a database request as a fallback allocator used in cases where specific statement allocators aren't available.

This allocator is typically large if many record locks exist. You can check the current record locks via SQL: "HANA_Locks_Transactional_Current" (SAP Note 1969700).

The allocator is purged asynchronously during delta merge (SAP Note 2057046) and column unload (SAP Note 2127458). Only an unload guarantees that all entries for the related table are completely purged. There is no possibility to map allocations to specific tables.

In systems with mass modifications it is normal that this allocator can grow and remain at a certain size although there are no current record locks. In general this does neither indicate a memory leak nor a bottleneck. In case of permanent sizes of more than 50 GB a more detailed analysis is useful.

See question "Which general optimizations exist for reducing the SQL statement memory requirements?" below in order to make sure that SQL statements are executed as memory-efficient as possible.

This allocator is typically quite small, but in context of the problem described in SAP Note 2253017 (SAP HANA Rev. 100 - 102.02) it can already become critical in case of small sizes >= 2 MB.

Pool/DocidValueArray

See question "Which general optimizations exist for reducing the SQL statement memory requirements?" below in order to make sure that join SQL statements are executed as memory-efficient as possible.

Pool/DPServerFramework
Pool/DPServerStatsRequestIfacerAllocator

These allocators are used by the data provisioning server (dpserver) that is used in smart data integration (SDI) scenarios (SAP Note 2400022).

The following known reasons for large and rising allocator sizes exist:

• SAP Note 2542700: Memory leak accessing remote cluster tables (SAP HANA <= 1.00.122.12, <= 2.00.012.02, <= 2.00.021)
• SAP Note 2643641: Risk of increased memory requirements in context of streaming
• SAP Note 2749005: Memory leak in context of change data capture (CDC)

Pool/DSO/DSORead
Pool/DSO/DSOUpdate

These allocators temporarily store data during DSO operations in BW like DSO_ACTIVATE_PERSISTED, DSO_ROLLBACK_PERSISTED, DSO_ACTIVATE_CHANGES and DSO_ROLLBACK_CHANGES. Once these activities are finished, the majority of the allocated memory is released.

Pool/DynamicCachedView
Pool/DynamicCachedView/ViewMatching

These allocators contain information related to the dynamic result cache (SAP Note 2506811).

Pool/entityCache

This allocator contains MDX entity cache information. You can use SQL: "HANA_Memory_Caches_Overview" and SQL: "HANA_Memory_Caches_Entries"(SAP Note 1969700) with CACHE_NAME = 'MdxEntityCache' to display and understand details about the current utilization of the entity cache.

The life time of entries in the entity cache doesn't depend on the execution of the underlying SQL statements, they are maintained independently. The entity cache is part of the SAP HANA resource container that is shrunk whenever the memory gets scarce. It is unloaded with a higher priority than columns so that a large cache size isn't necessarily critical.

See SAP Note 2502256 for more information related to SAP HANA caches.

Starting with SAP HANA 2.0 SPS 03 the cache can be cleared using the following command:

ALTER SYSTEM CLEAR CACHE ('MdxEntityCache')

Pool/ESX

See question "Which general optimizations exist for reducing the SQL statement memory requirements?" below in order to make sure that join SQL statements are executed as memory-efficient as possible.

The Extended SQL Executor (ESX, SAP Note 2599949) uses Pool/ESX for storing runtime data.

The following scenarios can cause an increased memory consumption:

• SAP HANA 2.00.000 - 2.00.023: Memory leak in context of PlanViz executions (SAP Note 2597818)
• SAP HANA 2.00.000 - 2.00.023: Large memory consumption in context of UNION ALL (SAP Note 2746957)

Pool/Exception

This allocator is used in context of exception handling. You can use SQL: "HANA_Threads_ThreadSamples_FilterAndAggregation" (LOCK_NAME = 'throwHelperSection', AGGREGATE_BY = 'HASH') to identify database requests with a significant amount of exception handling.

Pool/ExecutorPlanExecution

See question "Which general optimizations exist for reducing the SQL statement memory requirements?" below in order to make sure that join SQL statements are executed as memory-efficient as possible.

Pool/FemsCompression/CompositeFemsCompression

The form element selection (FEMS) compression is used for BW queries with execution modes 2 and 3 in order to reduce the amount of data transferred to the BW OLAP engine within SAP HANA. In some cases FEMS can result in increased memory requirements. See BW on HANA and the Query Execution Mode for more information related to BW query execution modes.

As a local workaround you can check if executing the query in question in execution mode 0 is an acceptable alternative. Also execution mode 2 instead of 3 is worth a try, because the underlying FEMS activities are different and may not run the same issues.

As a global workaround you can disable FEMS compression in method _GET_TREX_REQ_FLAGS_READ of class CL_RSDRV_TREX_API_STMT by commenting the following line with a leading '*' (see pilot SAP Note 1828751):

r_trex_req_flags = r_trex_req_flags + 33554432.

As this will lead to disadvantages in other areas (e.g. increasing amount of transmitted data), you should undo this change once you have understood and fixed the reason for the high FEMS related memory consumption.

Pool/Filter

See question "Which general optimizations exist for reducing the SQL statement memory requirements?" below in order to make sure that join SQL statements are executed as memory-efficient as possible.

This allocator is used in different contexts, e.g.:

• Pruning (join engine, OLAP engine, TableUpdate, TRexApiSearch)
• Hierarchy filter analysis

In general the memory should be released once the related database request is finished.

Pool/FRSWLockAllocator

Starting with SAP HANA 1.00.122.13 and 2.00.010 read write locks are no longer stored in the Pool/Statistics allocator, instead they are maintained in the dedicated Pool/FRSWLockAllocator ("fast read slow write lock allocator"). In case of a large size you can check for read write lock details via SQL: "HANA_Locks_Internal_LockWaits_Overview" (LOCK_TYPE = 'READWRITELOCK') available via SAP Note 1969700.

With SAP HANA 2.0 the space consumption of this allocator is reduced compared to SAP HANA 1.0. A further reduction is introduced with SAP HANA 2.0 SPS 02 because the granularity level was reduced from core to CPU socket.

The following known issues with a high number of recorded locks exist:

• SAP HANA <= 1.00.122.17, <= 2.0 SPS 00: PlanInfoLock
• SAP HANA <= 1.00.122.17, <= 2.0 SPS 00: PreferredRoutingLocations

See SAP Note 1999998 for more information related to SAP HANA locks.

If SQL: "HANA_Locks_Internal_LockWaits_Overview" respectively M_READWRITELOCKS doesn't return an amount of locks that can explain the growth of the allocator, the problem may be caused by unused (and therefore not reported) locks. In this case you can use the following hdbcons command (SAP Note 2222218) to dump the existing read write locks in a file rw_out.txt for later analysis:

hdbcons 'readwritelock l'

This command can generate a huge output of several GB. In order to reduce the output to the important mapping of locks and related counts you can use awk / Perl and create a file rwlocks.pl with the following content:

#!/usr/bin/perl
use strict;
my (%word, $key);
while(<>)
{ chomp $_;
  $key = $_;
  if(! defined $word{$key}) { $word{$key} = 1; } else { ++$word{$key}; }
  foreach $key (keys(%word)) { print "$key --> $word{$key}\n"; 
}

Now you can run hdbcons and evaluate the output with the script:

hdbcons 'readwritelock l' |grep M_READWRITELOCKS | awk -F\( '{print $1}' |awk -F: '{print $2}'| rwlocks.pl

A large and rising number of the following locks can be caused by blocked garbage collection (SAP Note 2169283):

• DeltaRowIDReadWriteLock
• HashIdCounters
• MVCCSyncLock

Pool/hierarchyBlob
Pool/hierarchiesItab

These allocators contain hierarchy cache and MDX hierarchy cache information that is populated when you query SAP HANA views with hierarchies. While the Blob allocator contains the core index, the Itab allocator caches secondary data. You can use SQL: "HANA_Memory_Caches_Overview" and SQL: "HANA_Memory_Caches_Entries" (SAP Note 1969700) with CACHE_NAME = '%Hierarchy%Cache' to display and understand details about the current utilization of the hierarchy cache.

The life time of entries in the hierarchy cache doesn't depend on the execution of the underlying SQL statements, they are maintained independently. The hierarchy cache is part of the SAP HANA resource container that is shrunk whenever the memory gets scarce. It is unloaded with a higher priority than columns so that a large cache size isn't necessarily critical.

If hierarchies / caching isn't required, you can disable it by setting cache=false in the hierarchy definitions, 'Drill Down Enablement' = ' ' (instead of 'Drilldown') in SAP HANA Studio or globally by disabling it with the following parameter:

indexserver.ini -> [cache] -> hierarchies_transactional_cache_enabled = 'false' 

See SAP Note 2502256 for more information related to SAP HANA caches.

Starting with SAP HANA 2.0 SPS 03 the cache can be cleared using the following command:

ALTER SYSTEM CLEAR CACHE ('HierarchyCache')
ALTER SYSTEM CLEAR CACHE ('HierarchyCacheNoInvalidate')




ALTER SYSTEM CLEAR CACHE ('HierarchyItabCache')
ALTER SYSTEM CLEAR CACHE ('MDXHierarchyCache')

Pool/HierarchyFunctionsGeneralExec
Pool/HierarchyFunctionsIncrementalLoad
Pool/HierarchyFunctionsSingleton

These allocators are used for the cache for SQL based hierarchies.

See SAP Note 2502256 for more information related to SAP HANA caches.

Starting with SAP HANA 2.0 SPS 03 the cache can be cleared using the following command:

ALTER SYSTEM CLEAR CACHE ('HierarchySqlFunctionCache')

Pool/ICT

The internet communication toolkit (ICT) is for example used in context of http requests via xsengine. A growth of Pool/ICT can be caused by a memory leak with SAP HANA 1.00.121 - 1.00.122.04 (SAP Note 2398507). As a workaround for this specific bug the following SAP HANA parameter can be set:

xsengine.ini -> [httpserver] -> enable_ict_eyecatcher = false 

Pool/IndexRebuildAllocator

This issue can happen with SAP HANA 1.0 SPS 07 and SPS 08. See SAP Note 2005478 and set the following parameter as a workaround in order to disable row store index rebuilds during startup:

indexserver.ini -> [row_engine] -> use_jobex_index_rebuild = false

Pool/IndexVector
Pool/IndexVectorAligned

This allocator is used in different contexts like table optimizations, column load, column write, binary import or index creation. A temporary large value is typically caused by delta merges (SAP Note 2057046) of tables with paged attributes (SAP Note 1871386), e.g. in the context of data aging (SAP Note 2416490).

Pool/itab can be used for different purposes:

• Intermediate result sets (not part of resource container, released after statement execution)
• MDX hierarchy cache (part of resource container, released in context of resource container shrinks or when MDX hierarchy cache is cleared or limited)
• Calculation engine node cache (part of resource container, released in context of resource container shrinks or when related requests like planning sessions are closed)

Therefore it is useful to check if a growth of Pool/itab corresponds to a certain extent to increased cache sizes (SAP Note 2502256) because in this case an increased size and growth can be normal and it is not an indication for a memory leak / memory release issue. A large and rising Pool/itab allocator in context of the MDX hierarchy cache is often a consequence of the fact that results for columns corresponding to custom view attributes are stored in the cache. This is currently also done unnecessarily for property columns and this behavior can significantly increase the memory footprint. Another indication of this problem is a large size of table CS_VIEW_ATTRIBUTES_.

The size of the MDX hierarchy cache and the related Pool/itab entries is reduced automatically during resource container shrinks when memory gets scarce. A manual reduction is usually not required, but can be achieved in the following different ways:

• SAP HANA 1.0: Resource container shrink (e.g. via "resman shrink" option of hdbcons or unload_upper_bound configuration)
• SAP HANA 2.0: ALTER SYSTEM CLEAR CACHE ('MdxHierachyCache')
• Configure parameter indexserver.ini -> [mdx] -> cache_entry_timeout / cache_entry_timeout_action as described in SAP Note 2502256 in order to make sure that entries are marked as stale and evicted

The following SAP Notes describes problem scenarios that can be responsible for an increased size of Pool/itab:

• SAP Note 2789785, <= 1.00.122.24: Memory leak calling virtual procedure in context of smart data integration (SDI, SAP Note 2400022)

If caches or bugs aren't responsible for the Pool/itab size you can check question "Which general optimizations exist for reducing the SQL statement memory requirements?" below in order to make sure that SQL statements are executed as memory-efficient as possible.

If no explanation for a large and rising Pool/itab allocator is found, an itab leak trace can be activated as described in SAP Note 2074981 (SAP internal).

See question "Which general optimizations exist for reducing the SQL statement memory requirements?" below in order to make sure that SQL statements are executed as memory-efficient as possible.

If no explanation for a large and rising Pool/itab allocator is found, an itab leak trace can be activated as described in SAP Note 2074981 (SAP internal).

This allocator is required in certain scenarios when translation tables are created to support join operations. See SAP Note 1998599 for more information related to translation tables.

See question "Which general optimizations exist for reducing the SQL statement memory requirements?" below in order to make sure that SQL statements are executed as memory-efficient as possible.

This is the main join engine allocator that should normally not be used for significant memory allocations. Instead sub-allocators are used. If you see a high allocation, please check if also some sub-allocators are significantly filled. If yes, proceed with the analysis based on the Pool/JoinEvaluator/* sub allocators as described below.

SAP Note 2370588 describes a problem that results in an increased size for Pool/JoinEvaluator, but at the same time also the sub-allocator Pool/JoinEvaluator/JECalculate/Results is extremely large.

A large size of Pool/JoinEvaluator has been observed with SAP HANA Rev. 122.05 in combination with fast data access (FDA), so you can consider deactivating FDA for FOR ALL ENTRIES as described in SAP Note 2399993 via rsdb/prefer_join_with_fda and dbs/hdb/prefer_join_with_fda = 0.

See question "Which general optimizations exist for reducing the SQL statement memory requirements?" below in order to make sure that SQL statements are executed as memory-efficient as possible.

This allocator is usually linked to SAP HANA SQL statement processing in call stack modules like AttributeEngine::AttributeApi::jeGetDictAndDocs and JoinEvaluator::JEDistinctAttribute::getDictAndDocs.

Among others the following scenarios can be responsible for a significant growth of this allocator:

• Check if inefficient joins of partitioned tables are responsible and reduce or optimize partitioning.
• Check for COUNT DISTINCT operations on large (partitioned) tables and columns with many distinct values (SAP Note 2000002 -> "What are typical approaches to tune expensive SQL statements?" -> "High runtime of COUNT DISTINCT").
• This allocator may also grow when an index is created because the join engine takes over some data processing.

Pool/JoinEvaluator/JECalculate
Pool/JoinEvaluator/JECalculate/TmpResults
Pool/JoinEvaluator/JECreateNTuple
Pool/JoinEvaluator/JEPreAggregate
Pool/JoinEvaluator/JEStep1
Pool/JoinEvaluator/JEStep2
Pool/JoinEvaluator/NTuple

See question "Which general optimizations exist for reducing the SQL statement memory requirements?" below in order to make sure that SQL statements are executed as memory-efficient as possible.

If you can't directly identify the SQL statements responsible for the memory growth, you can use SQL: "HANA_Threads_ThreadSamples_FilterAndAggregation" (THREAD_DETAIL = '%(JE%', AGGREGATE_BY = 'HASH, THREAD_DETAIL') available via SAP Note 1969700 to check for SQL statements with a significant processing time in related join engine functions.

Consider setting the hint USE_OLAP_PLAN (SAP Note 2142945) for testing purposes in order to check if a switch from join engine to OLAP engine works and results in a reduced memory consumption.

Huge allocations in Pool/JoinEvaluator/JECreateNTuple in combination with anti joins (e.g. EXCEPT) and call stacks in JoinEvaluator::LoopJob::findJoinPairsTL_native can be caused by a SAP HANA bug that is fixed with Rev. 1.00.122.12 and 2.00.010. With SAP HANA >= 2.0 SPS 02 the fix is enabled per default. With SAP HANA <= 2.0 SPS 01 the fix is disabled per default and can be activated with hint CONSERVATIVE_CS_ANTI_JOIN_ESTIMATION or globally with the following parameter:

indexserver.ini -> [sql] -> conservative_cs_anti_join_estimation_enabled = true

As a workaround the NO_GROUPING_SIMPLIFICATION hint (SAP Note 2142945) can be used. If triggered by BW / MDX, you can also disable the RSADMIN parameter MDX_F4_USE_SQL (SAP Note 1865554).

Large sizes for Pool/JoinEvaluator/JECreateNTuple and Pool/JoinEvaluator/NTuple were observed when replicated tables (SAP Note 2340450) are accessed. This problem is fixed with SAP HANA >= 2.00.035.

Pool/JoinEvaluator/JEEvalPrecond

See question "Which general optimizations exist for reducing the SQL statement memory requirements?" below in order to make sure that SQL statements are executed as memory-efficient as possible.

This allocator is also used to cache metadata (modules TRexConfig::CachedMetaDataBase::initAllAttributeAccessors, TRexConfig::CachedMetaDataBase::getNameToColumnIdx, TRexConfig::CachedMetaDataBase::getAttributePosition, TRexConfig::CachedMetaData::CachedMetaData) for the whole life time of the statement in the SQL cache. So in case of a large SQL cache and many statements processed by the join engine it is possible that this allocator increases over time and remains at this level. Clearing the SQL cache would implicitly reduce the allocator size. See SAP Note 2124112 for more information related to parsing and SQL cache.

See question "Which general optimizations exist for reducing the SQL statement memory requirements?" below in order to make sure that SQL statements are executed as memory-efficient as possible.

Check if the distribution of involved tables across nodes is already optimal or if you can adjust it so that less inter-node data transfer is required. See SAP Note 2081591 for more information about SAP HANA table distribution.

Consider setting the hint USE_OLAP_PLAN (SAP Note 2142945) for testing purposes in order to check if a switch from join engine to OLAP engine works and results in a reduced memory consumption.

Pool/JoinEvaluator/JEAssembleResults
Pool/JoinEvaluator/JEAssembleResults/Results
Pool/JoinEvaluator/JECalculate/Results
Pool/JoinEvaluator/JERequestedAttributes/Results

See question "Which general optimizations exist for reducing the SQL statement memory requirements?" below in order to make sure that SQL statements are executed as memory-efficient as possible.

If you can't directly identify the SQL statements responsible for the memory growth, you can use SQL: "HANA_Threads_ThreadSamples_FilterAndAggregation" (THREAD_DETAIL = '%(JE%', AGGREGATE_BY = 'HASH, THREAD_DETAIL') available via SAP Note 1969700 to check for SQL statements with a significant processing time in related join engine functions.

This allocator can grow considerably when late materialization isn't used. For some reasons (e.g. bugs described in SAP Note 1975448) the following parameters may be increased, resulting in higher memory requirements:

indexserver.ini -> [search] -> late_materialization_threshold
indexserver.ini -> [search] -> late_materialization_threshold_for_insert

Unset these parameters as soon as you have another solution in place (e.g. a revision level with included bug fix).

Consider setting the hint USE_OLAP_PLAN (SAP Note 2142945) for testing purposes in order to check if a switch from join engine to OLAP engine works and results in a reduced memory consumption.

Other reasons for a high memory consumption are:

• SAP Note 2174236 (bug in SAP HANA Rev. 91, fixed with Rev. 92)
• SAP Note 2260972 (inappropriate implementation of statistics server procedures)
• SAP Note 2370588 (inappropriate coding of S/4HANA migration routines)
• Increased allocation due to missing calc view unfolding in context of BETWEEN filter with decimal notation (fixed with >= 1.00.122.15, >= 2.00.012.04 and 2.00.024)

See question "Which general optimizations exist for reducing the SQL statement memory requirements?" below in order to make sure that SQL statements are executed as memory-efficient as possible.

This allocator is used when join engine results have to be sent from one node to another in scale-out scenarios.

Translation tables are required to map value IDs of join column values. SAP Note 1998599 describes how they can be configured in order to optimize memory consumption.

In certain scenarios a significant memory requirement is linked to caching of translation tables related to joins with temporary tables. As of SAP HANA Rev. 102.02 translation tables related to temporary table joins are no longer kept. With SAP HANA SPS 09 and Rev. 97.02 and higher you can set the following parameter:

indexserver.ini -> [joins] -> cache_temp_translation_tables = 'false'

See SAP Note 2217936 for more information.

See question "Which general optimizations exist for reducing the SQL statement memory requirements?" below in order to make sure that SQL statements are executed as memory-efficient as possible.

An increased size during an S/4HANA migration can be a consequence of the issue described in SAP Note 2370588.

The kernel sentinel takes over kernel monitoring tasks from the previous MVCC anti ager implementation. SAP Note 2815963 describes a problem with SAP HANA 2.00.040 - 2.00.041 that can result in an increased allocator size.

Pool/L/jit/MetaData
Pool/L/llang/Debuggee

These heap allocators contain L related information. With SAP HANA <= 2.00.023 the Pool/L/llang/Debuggee allocator is not part of the SAP HANA resource container and so it can't be shrinked in case of low memory. This scenario can become critical in context of the SAP HANA Execution Engine (HEX) activation (SAP Note 2570371) with SAP HANA 2.0 SPS 02 when many parsed queries are still contained in the SQL cache and so the allocator size can be high. Starting with SAP HANA 2.00.024 this problem is fixed and the allocator will be part of the resource container so that it can be shrinked when memory is required.

As a workaround for SAP HANA <= 2.00.023 you can set the following SAP HANA parameters:

indexserver.ini -> [execution] -> compilation_strategy = always
indexserver.ini -> [execution] -> asynchronous_compilation = false

Clearing the SQL cache (SAP Note 2124112) can be an immediate action to reduce the allocator size with SAP HANA <= 2.00.023:

ALTER SYSTEM CLEAR SQL PLAN CACHE

Be aware that clearing the SQL cache will result in increased parsing requirements and so it should only be performed in exceptional situations.

With SAP HANA >= 2.00.037.00 this allocator can grow in context of HEX queries. This is not necessarily an issue because the allocator is part of the resource container and so data will be evicted in case of memory shortages and resource container shrinks. If required the size can be limited by setting unload_upper_bound. See SAP Note 2808956 for more details.

Pool/L/llang/Runtime/Local

See question "Which general optimizations exist for reducing the SQL statement memory requirements?" below in order to make sure that SQL statements are executed as memory-efficient as possible.

Llang queries may be manually created or are results of FOX, SQLScript or HEX (SAP Note 2570371). The allocator can grow if a large amount of strings or CLOB values is processed. The name of the Llang program can be found in the call stack, e.g. _SYS_PLE:20160126114423_4338930:TMPDATA in the following case:

20: 0x00007fdd4b55b8b1 in ljit::dynamic/_split_main_0+0x3870 at 
      fox/cen_"SAPSR3"."_SYS_PLE:20160126114423_4338930:TMPDATA".
      cv053_fox_LLangView.56A7F0213FB8EFC7E10000000AAA0052:0 (<unknown>)

If required, you can activate a trace for the ljit component on debug level (see SAP Note 2119087):

indexserver.ini -> [trace] -> ljit = 'debug'

Pool/LVCAllocator/LVCContainerDir
Pool/LVCAllocator/LVCContainerDir/LVCContainer_<id>
Pool/LVCAllocator/LVCObjectPageDir
Pool/LVCAllocator/LVC_ObjectPageDir

These allocators hold the actual liveCache data and so their sizes should correspond to the amount of liveCache data. See SAP Note 2593571 for more information related to liveCache.

Pool/malloc/hdbindexserver

This allocator can grow significantly in context of exception handling. You can use SQL: "HANA_Threads_ThreadSamples_FilterAndAggregation" (LOCK_NAME = 'throwHelperSection', AGGREGATE_BY = 'HASH') to identify database requests with a significant amount of exception handling.

Pool/malloc/libdbrsa16_r.so
Pool/malloc/libdbrsa17_r.so

These libraries are used for functionalities in context of Sybase IQ remote accesses. In SAP HANA contexts these accesses are usually related to smart data access (SDA, SAP Note 2180119).

There is a memory leak in context of Sybase IQ accesses with Open SSL and PKCS 12 certificates that is fixed with Sybase IQ levels >= 16.1 SP03 11616, >= 16.1 SP02 11921 and >= 16.1 SP01 12021.

Pool/malloc/hdbnameserver

This allocator is used for temporary nameserver data structures that are e.g. used in context of Python activities triggered by actions like a full system info dump (SAP Note 2573880) or a performance trace (SAP Note 2520774).

Pool/malloc/libc.so.6

This allocator is used when memory allocation is done by the Linux libc.so library, e.g. in the context of file system accesses like __alloc_dir and System:UX:opendir. If you see this allocator in the context of an out-of-memory situation, you can assume that it is only a victim and not responsible for OOM. If for example the compileserver issues an OOM when allocating memory for Pool/malloc/libc.so.6, you should check the indexserver at first, because very likely it has consumed all available memory before.

Pool/malloc/libhdbbasement.so

A large and growing size can be caused by the following reasons:

• A memory leak in SAP HANA <= 1.00.122.06 can result in growth of this allocator related to module TrexThreads::InheritableLocalStorage::cloneMap. This problem is fixed with SAP HANA 1.00.122.07. This can also happen in consistency check contexts (SAP Note 2547516).
• Using the function profiler with SAP HANA <= 1.00.122.16, <= 2.00.024.01 and 2.00.030 can result in a growing allocator size (SAP Note 2637828).

Pool/malloc/libhdbcalcengine.so
Pool/malloc/libhdbcalcengineapi.so

See question "Which general optimizations exist for reducing the SQL statement memory requirements?" below in order to make sure that SQL statements are executed as memory-efficient as possible.

The following individual reasons can be responsible for increased allocator sizes:

• If you observe a growth of this allocator in combination with calculation engine processing (e.g. TREXviaDBSL, call stack modules like TrexCalculationEngine::Optimizer::optimizeHierarchyJoinOverMultiprovider and TrexCalculationEngine::CombineNonRootAggrOverMpRule::applyAggrOverHierachyJoin), you face a SAP HANA bug that is fixed with SAP HANA Rev. 97.02 and 102.
• SAP Note 2374935 describes a memory leak in the context of calculation scenario modeler objects that is fixed with SAP HANA Rev. 112.07 and 122.04.

Pool/malloc/libhdbcalcenginepops.so

See question "Which general optimizations exist for reducing the SQL statement memory requirements?" below in order to make sure that SQL statements are executed as memory-efficient as possible.

In most cases cePopInternalJoin will be the main contributor for the allocator size. As a workaround you can use calculation view unfolding, e.g. via CALC_VIEW_UNFOLDING hint (SAP Note 2142945).

Pool/malloc/libhdbcsapi.so

See question "Which general optimizations exist for reducing the SQL statement memory requirements?" below in order to make sure that SQL statements are executed as memory-efficient as possible.

Additionally you can check for the following specific constellations:

• If you observe a growth of this allocator in combination with calculation engine processing (e.g. TREXviaDBSL, call stack modules like TrexCalculationEngine::Optimizer::optimizeHierarchyJoinOverMultiprovider and TrexCalculationEngine::CombineNonRootAggrOverMpRule::applyAggrOverHierachyJoin), you face a SAP HANA bug that is fixed with SAP HANA Rev. 1.00.97.02 and 1.00.102.
• With SAP HANA <= 1.0 SPS 08 a large size of this allocator can be caused by the creation of join statistics. These statistics are dynamically created during the first execution of a specific join after a restart of SAP HANA. If the same kind of join is concurrently started in many different transactions, the efforts and memory requirements are also multiplied, because each transaction calculates the join statistics individually. As a workaround you can execute a critical join individually before running it with a higher parallelism. As of SAP HANA 1.0 SPS 09 the join statistics creation is improved and the problem no longer happens.
• This allocator can also grow when tables with large delta storages are accessed. Call stacks like TRexAPI::DeltaIndexManager::docIdSearch are indicators for this scenario. In this case you have to make sure that a reasonable merge strategy is implemented (SAP Note 2057046).
• Up to SAP HANA 1.0 SPS 12 this allocator is also used when the query result cache is configured (indexserver.ini -> [cache] -> query_result_cache = enabled; SAP Note 2014148). With newer patch levels dedicated result cache allocators are used instead.
• Large allocations can also be linked to queries with expensive fuzzy / text searches (call stack modules like ltt_adp::vector, TRexAPI::FreeStyleExecutor::addToken, TRexAPI::FreeStyleExecutor::createAllAlternatives, TRexAPI::FreeStyleExecutor::buildFSQuery).
• Large allocations from module OlapEngine::BwPopSearch::setQueryEntryInList in context of BW multiproviders (or composite providers) and FEMS can be caused by missing filter pushdown or problems with a convex hull optimization (SAP HANA >= 1.00.122.10). See SAP Note 2517443 and also consider to set indexserver.ini -> [calcengine] -> optimize_convex_hull_through_mp = 0 for testing purposes.
• With SAP HANA <= 1.00.122.15, <= 2.00.012.04 and <= 2.00.024 a memory leak in context of guided navigation searches (e.g. Enterprise Search) can result in a growing allocator size (SAP Note 2601475).

Pool/malloc/libhdbcs.so

See question "Which general optimizations exist for reducing the SQL statement memory requirements?" below in order to make sure that SQL statements are executed as memory-efficient as possible.

If you see particularly high values for this allocator, check the following typical reasons:

• Large indexes being created on a partitioned column store table can consume significant amounts of memory in these allocators. Check if you can avoid creating indexes on particularly large, partitioned column store tables. If the problem happens during a DMO activity, see SAP Notes 2257362 and 2578336 and make sure that critical indexes are created before the table data is loaded. Starting with SAP HANA 1.00.122.11 and 2.00.012.01 the memory footprint of index creations is optimized.
• Pool/malloc/libhdbcs.so may also grow during merges of large tables (see SAP Note 2057046)
• COUNT DISTINCT operations on large tables and columns with many distinct values can also be responsible for a growth of this allocator.
• Large allocations can happen in context of calculated columns (module ceProjectionPop, call stack modules AttributeEngine::CachedExpressionColumn::InternalCache::InternalCache, TrexCalculationEngine::cePlanOperationHelper::getCalculatedColumn). With more recent SAP HANA Revisions the heap allocator Pool/itab/expr is used instead.
• A memory leak in context of pattern searches can result in a memory leak with SAP HANA <= 2.00.037.00 (SAP Note 2780510). In this case you may observe call stacks like AttributeEngine::Delta::tree_iterator or AttributeEngine::Delta::complex_iterator in the block list or allocator stack trace (SAP Note 2222218).

Pool/malloc/libhdbcsaccessstatisticscache.so

This allocator contains allocations related to the column store table access statistics cache. See SAP Note 2785533 for more information how to configure and use it.

Pool/malloc/libhdbcsmd.so

This allocator contains transient metadata like the last delta merge time, column information or the number of values in main and delta storage. Additionally it is used by different SAP HANA engines for specific reasons. In order to understand the origination of the space consumption, you can generate a block list or allocator stack trace of the allocator using hdbcons (SAP Note 2222218).

Known scenarios are:

Pool/malloc/libhdbcsstore.so

This allocator contains administrative column store information (like parts of the row lock information and transaction handling) and may grow in case of many locks or blocked garbage collection.

If much memory is allocated by ptime::LinkHash / TrexStore::LockMapEntry*, it can be caused by an infrequent row lock link hashmap garbage collection. As a workaround you can trigger this garbage collection by unloading and reloading tables with a high INSERT / DELETE load. The problem is fixed with SAP HANA Revisions 102.04 and 111.

Pool/malloc/libhdbcstypes.so

This allocator contains information about column store data types including hybrid LOB information like memory LOB values or disk LOB references. As of SAP HANA SPS 10 it is common to see sizes between 10 and 50 GB for larger databases, depending on the amount of hybrid LOB values existing in the system.

This allocated can be treated similarly like the Pool/ColumnStoreTables allocators described above: Its size is closely linked to the column store table sizes (with a focus on hybrid LOB columns), and so it can mainly be reduced by reducing data stored in hybrid LOB columns. See SAP Note 2220627 for more information related to SAP HANA LOBs.

Pool/malloc/libhdbcswrapper.so

See question "Which general optimizations exist for reducing the SQL statement memory requirements?" below in order to make sure that SQL statements are executed as memory-efficient as possible.

The following scenarios can lead to an increased memory footprint of Pool/malloc/libhdbcswrapper:

• SAP HANA <= 1.00.122.16: Memory leak in context of mixed inverted index joins (SAP Note 2624305)

Pool/malloc/libhdbevaluator.so

See question "Which general optimizations exist for reducing the SQL statement memory requirements?" below in order to make sure that SQL statements are executed as memory-efficient as possible.

Database requests responsible for a growth of this allocator typically show evaluator specific modules like Evaluator::ThreeCode::run in their call stacks.

Pool/malloc/libhdbitab.so

See question "Which general optimizations exist for reducing the SQL statement memory requirements?" below in order to make sure that SQL statements are executed as memory-efficient as possible.

This allocator may be used for itab processing similarly to Pool/itab. In general Pool/malloc/libhdbitab.so should be small and larger memory allocations should happen for Pool/itab instead.

If it is large and growing, a memory leak can be responsible with Rev. <= 1.00.97.02 and Rev. 1.00.100 to 1.00.102.00.

Pool/malloc/libhdbmetadataobject.so

This allocator is linked to the SAP HANA metadata cache. A large and rising size can be a consequence of a bug that is fixed with SAP HANA >= 1.00.122.13. As a workaround clearing the SQL cache with "ALTER SYSTEM CLEAR SQL PLAN CACHE" can help to release no longer required entries and reduce the allocator size.

Pool/malloc/libhdbolap.so

See question "Which general optimizations exist for reducing the SQL statement memory requirements?" below in order to make sure that SQL statements are executed as memory-efficient as possible.

SAP Note 2373932 describes a memory leak in this allocator that is fixed with SAP HANA Rev. 112.07 and 120.

Pool/malloc/libhdbpartitioning.so

This generic allocator can grow in case of accesses to partitioned tables.

If you experience temporary or permanent large sizes, open a SAP incident for further analysis.

Pool/malloc/libhdbpythonbase.so

This allocator is related to a wrapper used for initializing and executing Python functions.

If it is too large it may be due to the pythontrace was enabled for too long. See KBA 2519536 - Nameserver ran out of memory with Pool/malloc/libhdbpythonbase.so as top allocator

Pool/malloc/libhdbrskernel.so

This allocator contains all dynamic row store memory allocations which aren't assigned to more specific allocators. With newer revisions the utilization of this allocator should reduce.

You can use the options "mm bl" of hdbcons and additionally create an allocation stack strace if required (SAP Note 2222218) to determine the top consumers inside the allocator. The following individual reasons for an increased size exist:

If you experience a large and rising size that can't be explained, open a SAP incident for clarification.

Pool/malloc/libhdbtableconsistencycheck.so

This allocator is related to the consistency check procedure CHECK_TABLE_CONSISTENCY (see SAP Note 1977584). You can limit the number of concurrent executions on different tables or run it at times with less concurrent workload in order to reduce the risk of critical memory allocations.

Pool/malloc/libsapcrypto.so

This allocator can grow with SAP HANA 2.00.020 to 2.00.021 due to a memory leak related to hash functions (e.g. HASH_SHA256). You need to restart SAP HANA in order to reclaim the allocated memory. A fix is available with SAP HANA 2.00.022.

Pool/M_CONSISTENT_VIEW_STATISTICS

This heap allocator stores consistent view details in context of calling monitoring view M_CONSISTENT_VIEW_STATISTICS. The size can be increased in case of blocked garbage collection (SAP Note 2169283).

Pool/mds

This allocator contains both the MDS cache and intermediate results in context of MDS requests (SAP Note 2670064).

See SAP Note 2502256 for more information for further details about the MDS cache.

If the allocator size can't be explained by the cache size or you see temporary peaks, it is probably dominated by statement executions.

See question "Which general optimizations exist for reducing the SQL statement memory requirements?" below in order to make sure that database requests are executed as memory-efficient as possible.

The memory is only allocated while an InA / MDS query is executed. You can reduce the memory footprint by reducing the amount of processed and returned data.

Pool/mds/CubeAxis

See question "Which general optimizations exist for reducing the SQL statement memory requirements?" below in order to make sure that database requests are executed as memory-efficient as possible.

The memory is only allocated while an InA / MDS query is executed. You can reduce the memory footprint by reducing the amount of processed and returned data. See SAP Note 2670064 for more information related to MDS.

Pool/mdx

As of SAP HANA SPS 09 several reasons for a high memory allocation of Pool/mdx are fixed.

Pool/Metadata/MetadataCache/MetadataGlobalCacheSlot

The metadata cache allocator was introduced with SAP HANA SPS 12 and is used to store metadata locally that otherwise has to be retrieved from a remote SAP HANA node. It can grow significantly if many DDL operations are executed, because DDL operations invalidate existing cache entries.

Reasons for increased sizes are:

• Blocked garbage collection (SAP Note 2169283)
• A problem exists in SAP HANA Rev. 120 to 122.03 that can result in increased metadata cache sizes. This problem is fixed with Rev. 122.04 (re-use of previous cache entries if possible).

Before SAP HANA SPS 12 the metadata information was stored in temporary row tables and so the allocator Pool/RowEngine/RSTempPage was used.

As a workaround in case of large metadata cache sizes you can clear the it manually:

ALTER SYSTEM CLEAR METADATA CACHE

This command will clear the cache on the SAP HANA node where you are currently logged on. Starting with SAP HANA 1.00.122.13 this command will clear the metadata cache on all SAP HANA nodes and you can add "AT '<host>:<port>'" if you want to clear only the cache for one specific host and service.

Pool/Metadata/SessionLocalItabContainer

This heap allocator exists with SAP HANA SPS 12 and higher and is used to store the following information:

• Session local data and session local metadata of session local temporary tables
• Session local data of global temporary tables

If you face a high size of this allocator you can check M_TEMPORARY_TABLES at first (e.g. using SQL: "HANA_Tables_Temporary_Tables" available via SAP Note 1969700).

Reasons for increased sizes are:

• Unnecessary high amount of temporary tables
• On Rev. 1.00.120 to 1.00.122.05 and 2.00.000 the session local metadata consumes larger amounts of memory than required. This is fixed with Rev. 1.00.122.06 and 2.00.001. See SAP Note 2418950 for more details.

Pool/NetworkChannelCompletionHandler

This allocator holds network channel related information. A high number of channels can increase the size of this allocator. The following options exist to optimize the allocator size:

• See SAP Notes 2222200 and 2382421 and make sure that a proper SAP HANA network configuration is in place.
• Avoid an unnecessary high amount of partitions that can increase the number of required network channels (SAP Note 2044468).

Pool/OptimizeCompression/<schema>:<table>
Pool/OptimizeCompression/<schema>:_SYS_SPLIT_<table>~<partition>

Allocators starting with Pool/OptimizeCompression are used during compression optimizations of tables. See SAP Note 2112604 and make sure that compressions area configured in a reasonable way. Furthermore you should take care that the size of individual tables / partitions remains on a reasonable level. Sizes above 50 GB should usually be avoided.

Pool/parallel
Pool/parallel/aggregates
Pool/parallel/align
Pool/parallel/compactcol
Pool/parallel/ihm
Pool/parallel/pop
Pool/parallel/temp_aggregates
Pool/parallel/temp_dimensions
Pool/parallel/temp_other

See question "Which general optimizations exist for reducing the SQL statement memory requirements?" below in order to make sure that SQL statements are executed as memory-efficient as possible.

If a high memory consumption is caused by the F4 value help mode D in BW environments (7.30 - 7.40), implement the BW correction available via SAP Note 2097025.

Consider setting the hint NO_USE_OLAP_PLAN (SAP Note 2142945) for testing purposes in order to check if a switch from OLAP engine to join engine works and results in a reduced memory consumption.

If the issue appears with a BW query, check if the problem improves using a different BW query execution mode. See BW on HANA and the Query Execution Mode for more information related to BW query execution modes.

If the issues is linked to SAP ABAP queries using fast data access (FDA), you can consider deactivating it as described in SAP Note 2399993.

If you face a high memory consumption related to DTP activities in BW, you can check SAP Note 2230080 for possible optimizations.

This allocator is populated at the beginning of a data backup in order to have a sorted list of page numbers for backup streaming. Once the data backup is finished, the space is released. The size of the allocator can be particularly large in case of large databases and / or a high amount of disk LOBs (SAP Note 2220627).

This allocator is used in context of backups and certain system replication activities. Itcan grow significantly on SAP HANA 2.00.040 - 2.00.041 in case of a resumed data shipping (SAP Note 2818480).

This allocator maps LOB containers to the persistence files. If it is particularly large, the following reasons are possible:

• A large amount of LOB data (can e.g. be checked via SQL: "HANA_Tables_LargestTables" -> LOB_GB in SAP Note 1969700)
• Unnecessarily high amount of LOB containers, improved with Revision 1.00.94

The main contributor to the allocator is usually the asynchronous system replication buffer, so it only has a significant size of asynchronous system replication is used and it closely depends on the value of the related parameter:

<service>.ini -> [system_replication] -> logshipping_async_buffer_size = <size_in_byte>

If you have to increase this buffer, you should only do it for the services with a high redo log generation, typically the indexserver (<service>.ini = indexserver.ini). Setting this parameter in global.ini technically also works, but as a consequence the increased space is allocated multiple times (for all different services), and so memory is wasted. Starting with SAP HANA 1.00.122.17 and 2.00.024.01 the default of this parameter is increased from 64 MB to 256 MB for the indexserver (SAP Note 2678164).

See SAP Note 1999880 for more information related to SAP HANA system replication.

The size of this cache is mainly linked to the setting of the following system replication parameter on secondary system replication site (SAP Note 1999880):

global.ini -> [system_replication] -> logshipping_replay_push_persistent_segment_count

The default value of 20 relates to a size of 1 GB. See SAP Note 2409671 for more information related to this setting.

This cache is used in system replication environments (SAP Note 1999880) with a log replay related operation mode like logreplay or logreplay_readaccess. It improves log replay performance by avoiding disk I/O. Per default 4 GB are used for the indexserver and 1 GB for other services. Normally no change to the default is required.

In special situations (e.g. as workaround in SAP Note 2405763) the size can be adjusted with the following parameter:

<service>.ini -> [system_replication] -> logshipping_replay_logbuffer_cache_size = <size_in_byte>

This allocator contains information about hybrid LOB values stored on disk (see SAP Note 2220627). Its size depends mainly on the amount of hybrid LOB values stored on disk.

It can grow in case of problems with LOB garbage collection. See SAP Note 2169283 for more information related to garbage collection.

This allocator is used to buffer up to four log segments in memory during recovery. The configured log segment sizes can be checked with SQL: "HANA_Logs_LogBuffers" (SAP Note 1969700). In case of a 1 GB log segment size you have to expect a memory allocation of 4 GB during recovery.

This allocator holds persistence metadata information and can grow in case of a growing persistence, e.g. due to many LOB files. See SAP Note 2400005 for more information related to SAP HANA persistence.

This is the parent allocator for different sub-allocators mentioned below like:

• Pool/PersistenceManager/PersistentSpace/DefaultLPA/DataPage
• Pool/PersistenceManager/PersistentSpace/DefaultLPA/LOBPage
• Pool/PersistenceManager/PersistentSpace/DefaultLPA/Page
• Pool/PersistenceManager/PersistentSpace/DefaultLPA/ShadowPage

A large size of the parent allocator is usually a consequence of an even larger size of one of the child allocators. You have to analyze and optimize the responsible child allocator in this case.

Pool/PersistenceManager/PersistentSpace/DefaultLPA/LOBControlblock
Pool/PersistenceManager/PersistentSpace/DefaultLPA/LOBPage

While disk LOB pages (SAP Note 2220627) are cached in the generic allocator Pool/PersistenceManager/PersistentSpace/DefaultLPA/Page with SAP HANA <= 2.0 SPS 02, they use the dedicated LOB allocators Pool/PersistenceManager/PersistentSpace/DefaultLPA/LOBPage (data) and Pool/PersistenceManager/PersistentSpace/DefaultLPA/LOBControlblock (metadata) with SAP HANA >= 2.0 SPS 03. Populating and releasing these allocators follows the same rules like described for Pool/PersistenceManager/PersistentSpace/DefaultLPA/Page.

You can influence the allocator size by configuring the LOB caching behavior as described in SAP Note 2220627 ("How can the SAP HANA memory utilization be influenced for disk LOBs?").

Starting with SAP HANA 2.0 SPS 04 you can determine the tables being responsible for the allocator size via SQL: "HANA_LOBs_LOBFiles" (SAP Note 1969700, output column MEM_SIZE_MB) respectively monitoring view M_TABLE_LOB_STATISTICS (column MEMORY_SIZE in byte).

The SAP HANA page cache stores blocks retrieved from disk similar to a file system cache. This can e.g. speed up the access to disk LOBs (SAP Note 1994962).

Starting with SAP HANA 2.0 SPS 03 the allocator is renamed from ".../Page" to ".../DataPage" and at the same time LOB pages are handled by the dedicated allocator ".../LOBPage".

You can check for the content of the allocator in terms of page types by executing "pageaccess a" with hdbcons (SAP Note 2222218).

If the page allocator grows due to a high amount of LOBs, you can influence LOB caching as described in SAP Note 2220627 ("How can the SAP HANA memory utilization be influenced for disk LOBs?").

If LOB garbage collection doesn't take place properly (SAP Note 2169283), LOB related pages aren't purged in time and so there can be an increased growth and size of the page allocator.

The page allocator size can be significant after a recovery, e.g. during a near zero downtime upgrade using SAP HANA system replication or a takeover (SAP Note 1999880). See SAP Note 2427897 for more details.

With SAP HANA 1.00.122.06 - 1.00.122.16, 2.00.000 - 2.00.024.03 and 2.00.030 it is recommended to disable caching for main (global.ini -> [persistence] -> internal_caching_for_main = false, SAP Note 2600030) in order to reduce the utilization of the page cache.

The pages cache also buffers history files and so garbage collection issues resulting in a higher amount of history files can implicitly result in an allocator growth. Related allocation stack modules can be e.g. DataAccess::GarbageCollectorJob::run. See SAP Note 2169283 for more information related to SAP HANA garbage collection.

Delta merges (SAP Note 2057046) temporarily write the data of the new main storage into the page allocator, so during delta merges of large tables the allocator size can significantly grow. The allocated space will be freed when the delta merge is finished. You can consider partitioning large tables (SAP Note 2044468) in order to reduce the temporary space overhead.

The page cache also contains the paged attributes cache (SAP Note 1871386). If you use paged attributes, you should check the following details:

• Check the size parameters described in SAP Note 2111649 and consider that the configured size contributes to the page cache size.
• Due to the bug described in SAP Note 2497016 it can happen that inverted index related pages are pinned in memory and more space is used for the paged attributes cache than intended (SAP HANA <= 1.00.122.09, <= 2.00.002.00, <= 2.00.011).

Due to a bug the size of this cache can be unnecessary large with Revisions 1.00.110 to 1.00.122.05. In order to avoid automatic reclaims with impact on the running system you can consider the following proactive measures (see SAP Note 2301382):

• Rev. 1.00.110 - 1.00.122.01: regular "resman shrink" scheduling
• Rev. 1.00.122.02 - 1.00.122.05: unload_upper_bound configuration

If the above scenarios don't apply and you see unloads or OOMs at a time where this allocator is still large, it is likely that the disk I/O peformance is not able to keep up with the data changes. In this case you should check your I/O stack for bottlenecks. This also applies to secondary system replication sites (SAP Note 1999880, "How can pending savepoints and large page cache sizes on secondary site be explained?"). See SAP Note 1999930 for more information.

Pool/PersistenceManager/PersistentSpace(0)/DefaultLPA/ShadowPage
Pool/PersistenceManager/PersistentSpace/DefaultLPA/ShadowPage

In some scenarios a copy of a page has to be created before the flush thread can write it down to disk:

• Critical savepoint phase
• Encrypted page
• Row store page

The page is deallocated as soon as the I/O write was successfully finished and acknowledged. A large size of this allocator can indicate a high I/O write volume or that the I/O stack isn't able to keep up with the flush thread activities. See SAP Note 1999930 for more information regarding I/O analysis.

This allocator is used to combine several smaller pages in chunks before writing them to disk. Once the write has finished, the allocated space is released. A temporary large allocator size is usually a consequence of the fact that the I/O stack can't handle the I/O requests fast enough. Typical reasons are bottlenecks in the I/O stack or a temporary spike in terms of I/O requests (e.g. due to big table optimizations, savepoints or IMPORT operations). See SAP Note 1999930 for more details about I/O analysis in SAP HANA environments.

This allocator contains row store control blocks and can grow significantly in case of a large row store. See SAP Note 2222277 and make sure to keep the row store at a reasonable size, e.g. via cleanup (SAP Note 2388483) or defragmentation (SAP Note 1813245).

This allocator contains row store data. Typically it is used on the secondary site of a system replication scenario where it is used for caching of row store pages, so that the row store can be created efficiently during takeover. Its size is related to the row store size on the primary system.

It is also used when the following SAP HANA parameter is set so that the row store uses heap memory instead of shared memory:

indexserver.ini -> [row_engine] -> use_shared_memory = false

Be aware that this is no recommended setting and the row store should reside in shared memory unless there are very specific reasons for a change.

Pool/PersistenceManager/PersistentSpace(0)/RowStoreLPA/Superblock
Pool/PersistenceManager/PersistentSpace/RowStoreLPA/Superblock

This allocator is used during SAP HANA startup to store the row store superblocks (including row store data) in heap while populating the row store shared memory. After startup its size is typically 0, but on secondary system replication sites it can remain with a large size for a longer time (with short term disposition). See SAP Note 2222277 and make sure to keep the row store at a reasonable size, e.g. via cleanup (SAP Note 2388483) or defragmentation (SAP Note 1813245).

If the large size of the allocator causes trouble (e.g. OOM during startup), you can temporarily disable the optimized row store load with the following parameter (SAP Note 2612205):

indexserver.ini -> [persistence] -> optimized_rowstore_load = false

This area contains the page cache related to liveCache (if operated as part of SAP HANA). Up to SPS 08 these pages aren't swappable. Starting with SAP HANA 1.0 SPS 09 the space is reclaimed automatically by SAP HANA whenever memory is required, so a large size is not critical. See SAP Note 2593571 for more information related to liveCache.

This heap allocator stores temporary data that isn't preserved on disk when SAP HANA is restarted.

Among others it contains data of temporary tables. It can significantly grow during repartitioning activities (SAP Note 2044468).

It can also be used in context of incremental backups or system replication (SAP Note 1999880) with delta_datashipping (module DataAccess::BackupChannel::BackupChannel, BackupMetaDataToDelete or BackupMetaDataToSend).

You can use the 'pageaccess a' option of hdbcons (SAP Note 2222218) in order to determine the main components of the TempLPA area.

Example:

### TemporaryPageAccess ##
PageType                           SizeCls      Disposition       hasRefs  | Count               MemorySize
ConvLeafPage                       256k         Temporary         yes      | 1                   262144   
TableContainerPage                 64k          Temporary         yes      | 102                 6684672  
TableContainerPage                 64k          InternalShortterm yes      | 1                   65536    
BackupMetaDataToDelete             16M          Shortterm         no       | 1375                23068672000

In this scenario you can see that more than 20 GB of the allocator size is linked to incremental backup / delta_datashipping allocations. Due to a bug with SAP HANA 2.00.040 BackupMetaDataToDelete isn't purged after the backup / shipping and so the pages are kept until they are evicted by a resource container shrink or until SAP HANA is restarted. You can switch to system replication operation mode logreplay in order to avoid the growth introduced by delta_datashipping.

This allocator can grow in context of many column store tables created with NO LOGGING. You can identify these tables via SQL: "HANA_Tables_TemporaryTables" (TEMPORARY_TABLE_TYPE = 'NO LOGGING', IS_COLUMN_TABLE = 'TRUE') available via SAP Note 1969700 and check from application perspective if a reduction or cleanup of these temporary tables is possible.

This allocator contains undo and cleanup file information and can grow significantly if persistence garbage collection is blocked. See SAP Note 2169283 for more information related to garbage collection and take appropriate actions to resolve garbage collection issues.

This allocator contains persistence information related to the new delta mechanism used as of SAP HANA 1.0 SPS 09 (L2 delta) and paged attributes (SAP Note 1871386). Up to SAP HANA 1.0 SPS 08 delta logs were stored in virtual files instead. The actual delta area in column store remains untouched from this allocator.

See SAP Note 2057046 and make sure that delta merges are properly configured and executed, so that the delta storage size of the tables remains on acceptable levels.

The allocator can grow in cases when persistence garbage collection is blocked (SAP Note 2169283).

This allocator is used to keep track of column store MVCC, e.g. by storing creation and deletion timestamps related to changes. Its size can be significant in context of a large column store table footprint. You can determine main contributors via SQL: "HANA_GarbageCollection_ColumnStore" (SAP Note 1969700, column MVCC_TOTAL_MB).

This allocator keeps track of free space in persistence containers with variable size. These containers are typically used by packed LOBs (SAP Note 2220627) and the container directory. A typical scenario for a large allocator size is free space in packed LOBs, e.g. after having deleted a significant amount of LOB values. A restart of SAP HANA may reduce the allocator size to a certain extent because some free space is then managed more efficiently. See SAP Note 2220627 ("Can packed LOBs be reorganized?") for more information about reducing the free space in packed LOBs.

A large size of this allocator is usually linked to a high number of existing disk LOBs. See SAP Note 2220627 and check if you can reduce the number of disk LOBs (e.g. by data management and archiving) or if you can activate packed LOBs (SAP HANA >= 2.0). Starting with SAP HANA 2.00.040 this allocator is no longer required in context of disk LOBs.

Also other contexts using virtual files (e.g. data provisioning, SAP Note 2400022) can result in an increased size of this allocator in some cases.

This heap allocator is linked to the planning engine (as e.g. used by BW integrated planning) and holds data used for housekeeping and consistency checks. The data life time is linked to the related planning session.

If the allocator size is significant for a longer time, you can check if dropping no longer required planning sessions can help to reduce the allocations (SAP Note 2169283 -> "How can garbage collection be triggered manually?" -> "Planning engine garbage collection").

If the allocator size is large in context of planning engine activities, you can check if dropping no longer required planning sessions can help to reduce the allocations (SAP Note 2169283 -> "How can garbage collection be triggered manually?" -> "Planning engine garbage collection").

FOX formula executions by the planning engine may require temporary helper structures that are allocated in Pool/PlanningEngine/Fox. They are dropped after the FOX planning function is finished. If a significant memory allocation - often in combination with Pool/itab - is seen, there may be a loop in the FOX script that has to be corrected.

Additionally you can check if dropping no longer required planning sessions can help to reduce the allocations (SAP Note 2169283 -> "How can garbage collection be triggered manually?" -> "Planning engine garbage collection").

You can use SQL: "HANA_Heap_PlanningEngine" (OBJECT_TYPE = 'LOOKUP DICTIONARY') available via SAP Note 1969700 in order to check for the main contributors and the creation times. After a restart of SAP HANA this allocator is empty and re-populated on demand.

You can use SQL: "HANA_Heap_PlanningEngine_Cleanup" (SAP Note 1969700) in order to drop no longer required runtime objects. Starting with SPS 10 SAP HANA automatically takes care for the cleanup.

If these steps don't help you can check if dropping no longer required planning sessions can help to reduce the allocations (SAP Note 2169283 -> "How can garbage collection be triggered manually?" -> "Planning engine garbage collection").

Pool/planviz/column store/plans
Pool/planviz/column store/plans/ParentCycleDetector
Pool/planviz/column store/PlanVizContext
Pool/planviz/column store/PlanVizContext/JsonAllocator
Pool/planviz/common/final results
Pool/planviz/common/strings
Pool/planviz/sql layer/PlanVizContext
Pool/planviz/sql layer/PlanVizContext/PlanVizParams

These allocators are used by PlanViz and the plan trace (see SAP Note 2119087). In order to keep their sizes at a reasonable level you should use the plan trace only as restricted as possible (in terms of time and traced statements).

See question "Which general optimizations exist for reducing the SQL statement memory requirements?" below in order to make sure that SQL statements are executed as memory-efficient as possible.

Related queries typically have query mediator related modules in their call stacks, e.g.:

QueryMediator::FilterProcessor::addFilterAsExpression
QueryMediator::FilterTranslation::SearchOperation

Starting with SAP HANA SPS 10 an optimization is implemented so that the problem is fixed in many cases.

As a workaround you can check if specifying the hint NO_CS_ITAB_IN_SUBQUERY helps to reduce the memory consumption. See SAP Note 2142945 for more information related to SAP HANA hints.

This buffer is used for received replication logs in context of table replication (SAP Note 2340450). It is released once the log is replayed. Large sizes can be a consequence of a temporary high amount of replication logs or of bottlenecks during replay.

A large size of these allocators is typically caused by a high number of memory objects. You can use SQL: "HANA_Memory_MemoryObjects" (SAP Note 1969700) or directly query M_MEMORY_OBJECTS in order to check for the number of existing memory objects.

A high number of memory objects for Persistency/Pages/Default and Persistency/Container/VirtualFile can be a consequence of a high number of cached disk LOBs (SAP Note 2220627). In this case you can consider to adjust LOB caching (SAP Note 2403124), perform a cleanup of tables with many LOBs (e.g. based on SAP Note 2388483) or switch medium sized LOBs on SAP HANA 2.0 to packed LOBs.

Pool/ResourceContainer/ResourceHeader contains resource headers that are never destroyed, so it will not reduce in size over time until SAP HANA is restarted.

This allocator stores static result cache information information with SAP HANA SPS 12 and higher. The static result cache is available as of SAP HANA SPS 11. See SAP Note 2336344 for more information related to the SAP HANA static result cache cache.

See SAP Note 2222200 and try to reduce the amount of connections and inter-node / inter-service communications in order to reduce the size of this allocator.

Check via SQL: "HANA_RowStore_TotalIndexSize" (SAP Note 1969700) if the size of the heap allocator is in line with the size of the row store indexes. If it is significantly larger, most likely a memory leak exists that can only be cleaned up by restarting SAP HANA. Upgrade to at least revision 83 in order to eliminate known memory leaks.

Due to a bug with Rev. <= 1.00.85.03 and Rev. 1.00.90 to 1.00.94 index garbage collection is not necessarily triggered in time and so this allocator can unnecessarily grow. With Rev. 1.00.85.04 and Rev. 1.00.95 a fix is delivered. See SAP Note 2169283 for more information related to garbage collection.

If the allocator size is in line with the index sizes, check if there are large tables with indexes in row store that can be cleaned (e.g. via SAP Note 2388483) or moved to column store. Check via SQL: "HANA_Indexes_Overview" (ORDER_BY = 'SIZE', SAP Note 1969700) if there are large indexes created on row store tables that are not required and can be dropped.

This allocator is an unspecific allocator for row engine memory. As all significant memory allocation should be assigned to dedicated allocators, Pool/RowEngine/GlobalHeap shouldn't allocate too much memory. Reasons for increased sizes are:

If you face another situation with a significant memory allocation in Pool/RowEngine/GlobalHeap, you can open a SAP incident for clarification.

This heap allocator is used when row store indexes are rebuilt, typically during / after SAP HANA restarts (SAP Note 2177064).

See question "Which general optimizations exist for reducing the SQL statement memory requirements?" below in order to make sure that SQL statements are executed as memory-efficient as possible.

This allocator stores small LOB values (default: <= 1024 byte) that are processed by database requests. Larger LOB values are stored in Pool/RowEngine/QueryExecution. If the Pool/RowEngine/LOB allocator is large, you should check for SQL statements requesting a large amount of records with LOB columns.

A large size of this allocator can indicate a high number of transactional locks (SAP Note 1999998) or garbage collection issues (SAP Note 2169283).

Additionally you can check the following known SAP HANA bugs resulting in increased sizes of this allocator:

This heap allocator contains information of in-memory monitoring views (M_* views). You can display the largest areas within Pool/RowEngine/MonitorView using "mm bl" with hdbcons (SAP Note 2222218) as described further below. In general you have to make sure that less data is collected in the critical monitoring views (e.g. by reducing the trace level).

Known issues are:

This allocator is required during parsing of database queries. Large sizes can be caused by complex SQL statements. Although parsing related this allocator considers the configured statement memory limit.

You can check the following known SAP HANA issues resulting in increased sizes of this allocator:

indexserver.ini -> [sql] -> default_segment_size = <segment_size_in_byte>

This heap allocator holds details during SQL plan optimization. The size is usually reasonable, but in some scenarios the number of allocator instantiations can be high and check ID M0470 ("Heap allocators with many instantiations") of the SAP HANA Mini Checks (SAP Note 1999993) may be flagged as potentially critical. Usually this issue is harmless and can be ignored. Starting with SAP HANA 2.0 SPS 04 a main allocator will be shared and the high number of instantiations disappears.

See question "Which general optimizations exist for reducing the SQL statement memory requirements?" below in order to make sure that SQL statements are executed as memory-efficient as possible.

To a minor extent every connection context allocates memory in these allocators, so a growth can also be a consequence of a particularly high number of connection contexts.

To a certain extent the allocator utilization per connection / statement context can be analyzed via SQL: "HANA_Memory_ContextMemory" (CATEGORY = '%Pool/RowEngine/QueryExecution/SearchAlloc') available via SAP Note 1969700. Be aware that there can be also allocations via generic implicit memory booking, not showing the explicit context name.

Additionally you can check the following known SAP HANA bugs resulting in increased sizes of this allocator:

This heap allocator is used for row store MVCC management during recovery operations (e.g. on secondary system replication sites and during database recoveries). It is available starting with SAP HANA 2.0 and it can increase in case of garbage collection issues (SAP Note 2169283). The following SAP HANA bugs exist that can result in an increased allocator size:

This allocator holds data related to temporary tables and NO LOGGING in row store. Check why many or large temporary row store tables exist and try to reduce it. Make sure that sessions are closed whenever possible, because this will drop related temporary tables.

See SAP Note 2000003 ("What kind of temporary and non-persisted tables can be created with SAP HANA?") for more information related to temporary and NO LOGGING tables.

Additionally you can check the following known SAP HANA bugs resulting in increased sizes of this allocator:

The SQL cache can be configured unnecessarily large because underlying issues like a lack of bind variables or varying IN LIST sizes are not recognized. See SAP Note 2124112 and make sure that the SQL cache is not configured larger than required.

Be aware that the heap allocator size can be up to three times larger than the size (in byte) configured with the following SAP HANA parameter:

<service>.ini -> [sql] -> plan_cache_size

Reason: In addition to the SQL plan cache itself, this allocator includes all other miscellaneous memory allocations such as data structures for managing SQL plan cache, monitoring view data and optimizer allocations (SAP Note 2502256).

Due to a SAP HANA bug on SAP HANA <= 1.00.122.13, <= 2.00.012.03 and <= 2.00.022 certain internal SQL cache statistics weren't considered for the plan cache size calculation and so the heap allocator could grow more than expected.

With SAP HANA Rev. <= 1.00.97.01 no proper cleanup happens when a temporary table is dropped, this bug is fixed as of Rev. 97.02.

Pool/RowEngine/Version
Pool/RowStoreTables/Version

Pool/RowEngine/ViewCache

Pool/RowTableUpdateAllocator

This allocator is used in context of updating row store tables. Due to a SAP HANA bug it can happen that memory isn't released in time. As a workaround you can clear the SQL cache:

ALTER SYSTEM CLEAR SQL PLAN CACHE

The bug is fixed with SAP HANA >= 122.10, 2.00.002.01 and 2.00.010.

See question "Which general optimizations exist for reducing the SQL statement memory requirements?" below in order to make sure that SQL statements are executed as memory-efficient as possible.

This allocator is more intensively used with SAP HANA Rev. 1.00.122.05. It works in a similar way like Pool/itab, so you can check that allocator for more information.

Among others it is used by the hierarchy cache, see allocator Pool/hierarchyBlob for more details.

This allocator is used for searches related to prepared statements. The life time of its content is linked to the related SQL cache entry, so a large SQL cache size can indirectly be responsible for an increased size of this allocator. Clearing the cache would implicitly also clean these allocations. See SAP Note 2124112 for more information related to SAP HANA parsing and the SQL cache.

You can run SQL: "HANA_Indexes_Overview" (INDEX_TYPE = 'FULLTEXT', ORDER_BY = 'SIZE') available via SAP Note 1969700 to display the existing fulltext indexes sorted by size. Check if particularly large fulltext indexes are really required. For example, a large index REPOSRC~SRC may exist to support the ABAP Sourcecode Search (SAP Note 1918229) and can be removed via transaction SFW5.

This heap allocator is used for the single value cache (SAP Note 2502256).

This allocator is linked to the Spatials option (SAP Note 2091935) and it is typically required for spatial joins, spatial clustering and for providing metadata for geometry attributes.

A memory leak can be responsible for a permanent growth on SAP HANA Revisions between 1.00.100 and 1.00.122.02. A fix is available with Revision 1.00.122.03.

This allocator is used for a rule based semantic check during SQL parsing (SAP Note 2124112). The data life time is similar to allocator Pool/SQLParserGlobal/SQLParserParse so you can check there for possible root causes and solutions.

This allocator is used in context of SQL parsing (SAP Note 2124112). The following issues are known:

• Memory leak fixed with SAP HANA >= 2.00.037 (SAP Note 2746759)

This allocator is used for preprocessing / rewriting after SQL parsing (SAP Note 2124112). The data life time is similar to allocator Pool/SQLParserGlobal/SQLParserParse so you can check there for possible root causes and solutions.

Check for design problems in the used SQLScript procedures.

If you face a high memory consumption with Rev. 1.00.100 to 1.00.101, a bug can be responsible (SAP Note 2312948) in context of XS engine calls. Upgrade to Rev. 1.00.102 or higher in order to fix it.

This allocator is used for memory requirements during SQLScript plan executions in L. It can grow significantly if a VARCHAR, NVARCHAR or LOB type is used within a loop, e.g.:

declare var lob;
while ...
  var = :var || "abc"

The allocated memory isn't released until the procedure is finished and so the memory requirements can be significant in case of many iterations.

Check if you can adjust the procedure design to avoid this critical scenario.

You can display the largest areas within Pool/Statistics using "mm bl" with hdbcons (SAP Note 2222218).

The following top allocators point towards memory statistics as highest contributor:

Execution::ContextAllocator::initImplicitStatementMemoryBooking
ltt::allocator_statistics::setCompositeLimit
MemoryManager::LimitInfo::LimitInfo
MemoryManager::MemoryCounter::MemoryCounter
MemoryManager::PoolAllocator::PoolAllocator
MemoryManager::StripedAllocator::allocateStriped

In this case the Pool/Statistics size mainly depends on the following factors:

• Number of records in M_CONTEXT_MEMORY (which is closely linked to the number of SQL connections)
• Number of records in M_HEAP_MEMORY
• Number of (logical) CPUs
• Activation of special features like memory tracking or statement memory limit

Example:

The factor of 96 byte in the calculation is a worst case estimation - depending on different factors it can vary between 64 and 96 byte in different environments.

If there are many records in M_HEAP_MEMORY (> 100000), you can check for the most frequent heap allocators using SQL: "HANA_Memory_TopConsumers" (DATA_SOURCE = 'CURRENT', AREA = 'HEAP', ORDER_BY = 'COUNT') of SAP Note 1969700.

The following individual reasons for a high Pool/Statistics allocation in context of memory exist:

• The amount of entries in M_CONTEXT_MEMORY among others depends on the amount of database requests cached on client side. In ABAP environments this is controlled by parameter dbs/hdb/stmt_cache_size (default: 1000 statements per connection). You can reduce it in order to minimize the M_CONTEXT_MEMORY entries and the Pool/Statistics size (SAP Note 2532199). In a real-life scenario the size of Pool/Statistics reduced by factor 4 after having reduced the value from 1000 to 100. Be aware that a reduction of this setting can increase the parsing activities, so you should monitor the performance effects. See SAP Note 2124112 ("Can there be also statement caches on client side?") for more information related to the ABAP client statement cache.
• A very high number of entries for Pool/RowEngine/QueryCompilation/SqlOptAlloc can be caused by a memory leak in Revisions up to 1.00.83.
• With SAP HANA Rev. <= 1.00.97.01 no proper cleanup happens when a temporary table is dropped, this bug is fixed as of Rev. 97.02.
• SAP HANA Revisions 1.00.100 - 1.00.102.03 and 1.00.110 - 1.00.112 can suffer from a memory leak in the context of XS engine calls (SAP Note 2313013)
• Many prepared statements in context of transactional LOBs and JDBC (SAP Notes 2220627, 2711824)

With SAP HANA >= 2.00.040 it is possible to reduce the size of Pool/Statistics required for context memory information by storing information per NUMA node rather than CPU core. This can be controlled by setting the following SAP HANA parameter to 'numa':

global.ini -> [memorymanager] -> composite_statistics_striping

The following values are possible:

• auto: internal decision, currently identical to 'core'
• core: core based statistics as before, i.e. higher memory requirements with optimal performance
• numa: NUMA node based statistics, i.e. reduced memory requirements with the risk of performance reductions

The following top modules indicate that lock statistics consume most space:

Synchronization::ReadWriteLock::ReadWriteLock
Synchronization::FastReadSlowWriteLock::allocateReaderItems

Large allocations for Synchronization::ReadWriteLock::ReadWriteLock can be caused by a memory leak with Rev. 1.00.100 to 1.00.101 which is fixed as of Rev. 1.00.102.

Starting with SAP HANA 1.00.122.13 and 2.00.010 read write locks are tracked in the dedicated allocator Pool/FRSWLockAllocator and no longer in Pool/Statistics. See "Pool/FRSWLockAllocator" for known issues in context of read write lock statistics.

Pool/StatisticsServer/ThreadManager/Stats::Thread_<num>
Pool/StatisticsServer/JobManager/Stats::Thread_<num>
Pool/StatisticsServer/JobManager/WriteLastValuesJob
Pool/StatisticsServer/LastValuesHolder

These allocators can become quite large if the standalone statistics server is used and a significant amount of monitoring data is available (e.g. large SQL plan cache, many connections). In order to optimize these allocators please proceed as described at "Which options exist to reduce the risk of SAP HANA memory issues?" -> "Statisticsserver optimizations" above.

Pool/StringContainer

See question "Which general optimizations exist for reducing the SQL statement memory requirements?" below in order to make sure that SQL statements are executed as memory-efficient as possible.

A temporary increase of Pool/StringContainer is possible during processing of large amounts of data, e.g.:

• Data load
• Index creation (improved with SAP HANA >= 1.00.122.11 and >= 2.00.012.01)
• Merge

When the utilization reduces again after the large operation, it is normally not critical.

Pool/TableConsistencyCheck

This allocator is related to the consistency check procedure CHECK_TABLE_CONSISTENCY (see SAP Note 1977584). You can limit the number of concurrent executions on different tables or run it at times with less concurrent workload in order to reduce the risk of critical memory allocations.

Pool/Text/AEText
Pool/Text/AEText/phrase_index
Pool/Text/AEText/split_document_index
Pool/Text/AEText/split_positional_index
Pool/Text/AEText/termset_container
Pool/Text/AEText/text_property_index

These allocators store specific parts of the data of fulltext indexes, so their size mainly depends on the size of existing fulltext indexes. See SAP Note 2160391 for SAP HANA indexes in general and fulltext indexes in particular.

Pool/TransientMetadataAlloc

This allocator stores temporary metadata information (object definitions; local on transaction / session level or global). The life time of some data is linked to the SQL cache, so you should check if this cache is defined larger than required (see SAP Note 2124112).

The following individual reason afor a large allocator exist:

• SAP HANA Revisions 100 to 102.04 and 110 to 112.01 can suffer from a memory leak bug when a procedure is called (SAP Note 2312994).

Pool/TransMgr

This pool contains data required for transaction management. The life time of data is limited to the transaction life time. A large size can be related to a high number of existing transactions. You can use SQL: "HANA_Transactions_CurrentTransactions" (SAP Note 1969700) to display all existing transactions. Also a high number of transactional locks (SAP Note 1999998) can be responsible for allocator growth. You can use SQL: "HANA_Locks_Transactional_Current" (SAP Note 1969700) to check for currently existing transactional locks. The allocator size can also increase when garbage collection is blocked (SAP Note 2169283).

With SAP HANA 2.00.030 to 2.00.033 the record lock structures may not be properly deallocated and so the allocator can grow unexpectedly. This issue is fixed with SAP HANA >= 2.00.034.

Pool/CacheFramwork/CacheMgr/CalcEngineNodeCache
Pool/TREXCache/CacheMgr/CalcEngineNodeCache

This allocator holds information related to the calculation engine node cache. See SAP Note 2502256 for more information.

Pool/CacheFramework/CacheMgr/CE_ScenarioModelCache
Pool/TREXCache/CacheMgr/CE_ScenarioModelCache
Pool/CacheMgr/CE_ScenarioModelCache

This heap allocator is used for the calculation engine model cache. Its size can be controlled by the following SAP HANA parameter (unit: KB):

indexserver.ini -> [calcengine] -> max_cache_size_kb

Starting with SAP HANA 2.0 SPS 03 the cache can be cleared using the following command:

ALTER SYSTEM CLEAR CACHE ('CE_ScenarioModelCache')

See SAP Note 2502256 for more information.

Pool/CacheFramework/CacheMgr/cs_access_statistics
Pool/TREXCache/CacheMgr/cs_access_statistics

This allocator contains column store table access statistics information in case the access statistics cache is activated. See SAP Note 2785533 for more information how to configure and use it.

Starting with SAP HANA 2.0 SPS 03 the cache can be cleared using the following command:

ALTER SYSTEM CLEAR CACHE ('cs_access_statistics')

Pool/CacheFramework/CacheMgr/CS_QueryResultCache[Realtime]
Pool/CacheFramework/CacheMgr/CS_QueryResultCache[TimeControlled]Pool/TREXCache/CacheMgr/CS_QueryResultCache[Realtime]
Pool/TREXCache/CacheMgr/CS_QueryResultCache[TimeControlled]Pool/CacheMgr/CS_QueryResultCache[Realtime]
Pool/CacheMgr/CS_QueryResultCache[TimeControlled]

These heap allocators are linked to the query result cache (SAP Note 2014148).

Starting with SAP HANA 2.0 SPS 03 the cache can be cleared using the following command:

ALTER SYSTEM CLEAR CACHE ('CS_QueryResultCache [Realtime]')
ALTER SYSTEM CLEAR CACHE ('CS_QueyResultCache [TimeControlled]')

Pool/CacheFramework/CacheMgr/CS_StatisticsCache
Pool/TREXCache/CacheMgr/CS_StatisticsCache
Pool/CacheMgr/CS_StatisticsCache

 This heap allocator is used for the column store statistics cache (SAP Note 2502256).

Starting with SAP HANA 2.0 SPS 03 the cache can be cleared using the following command:

ALTER SYSTEM CLEAR CACHE ('CS_StatisticsCache')

Pool/CacheFramework/CacheMgr/Currency/UnitConversion_RateQueriesResultCache
Pool/TREXCache/CacheMgr/Currency/UnitConversion_RateQueriesResultCache
Pool/CacheMgr/Currency/UnitConversion_RateQueriesResultCache

This heap allocator is used for the currency conversion cache (SAP Note 2502256). It is activated with the following parameter settings:

indexserver.ini -> [businessdb] -> cache = global
indexserver.ini -> [businessdb] -> cache_erp_currency_query_base_rates = true
indexserver.ini -> [businessdb] -> cache_erp_currency_query_rates = true

The cache is invalidated when underlying currency conversion tables like TCURR are modified.

Starting with SAP HANA 2.0 SPS 03 the cache can be cleared using the following command:

ALTER SYSTEM CLEAR CACHE ('UnitConversion_RateQueriesResultCache')

Pool/CacheFramework/CacheMgr/DataStatisticsAdviserCache
Pool/TREXCache/CacheMgr/DataStatisticsAdviserCache
Pool/CacheMgr/DataStatisticsAdviserCache

This heap allocator is used for the data adviser statistics cache (SAP Note 2502256).

Starting with SAP HANA 2.0 SPS 03 the cache can be cleared using the following command:

ALTER SYSTEM CLEAR CACHE ('DataStatisticsAdviserCache')

Pool/trex_wrapper_body

This allocator is used to wrap P*TIME / TREX communications, e.g. prepared execution plans when SQLScript calls calculation engine functionalities. Its life time is linked to the execution plan in the SQL cache - once the execution plan is evicted, also the memory in Pool/trex_wrapper_body is released.

See SAP Note 2124112 for more information related to parsing and SQL cache.

Pool/UdivListMgr/UdivListContainer

This allocator is responsible for managing multi-version concurrency control (MVCC), so the visibility of rows in different transactions.

In order to check for problems like long-running transactions you can proceed as described in "Which options exist to optimize the SAP HANA memory utilization?" -> "Transactional problems".

Pool/ValueArray
Pool/ValueArrayColumnDeserialize

See question "Which general optimizations exist for reducing the SQL statement memory requirements?" below in order to make sure that SQL statements are executed as memory-efficient as possible.

These allocators are closely linked to Pool/JoinEvaluator/JERequestedAttributes/Results:

• Pool/ValueArray was a previous name that is no longer used with current Revisions.
• Pool/ValueArrayColumnDeserialize is used when join engine results have to be sent from one node to another in scale-out scenarios.

Pool/XDictData

See question "Which general optimizations exist for reducing the SQL statement memory requirements?" below in order to make sure that SQL statements are executed as memory-efficient as possible.

This allocator stores dictionary data during query processing in the OLAP engine. It can grow significantly if columns with many distinct values are processed and filters don't exist or aren't pushed down.

Pool/XSEngine/XSJobScheduler/_<application>
Pool/XSEngine/XSJobScheduler/_<application>/_<job_name>

These heap allocators contain information related to XS engine jobs. Every job creates an own instantiation of the allocator, so the number of allocator instantiations can be particularly high. The size is at the same time typically at a reasonable level. Starting with SAP HANA 1.00.122.16, 2.00.012.05 and 2.00.024 jobs with the same name use the same allocator and so the amount of allocator instantiations can be significantly lower.

There is no way to purge old jobs from the allocator. After a SAP HANA restart the allocator starts again from scratch.

StackAllocator

This allocator contains thread stack data. Large sizes are typically caused by a large number of threads or be large settings of the following stack size parameters:

global.ini -> [threads] -> default_stack_size_kb
global.ini -> [threads] -> worker_stack_size_kb

These parameters should normally remain on default values, adjustments are only required in specific situations (e.g. SAP Note 1847202).

VirtualAlloc

This allocator is related to memory allocations outside of the standard SAP HANA memory management, e.g. related to Java Virtual Machine (JVM).

Overview of all memory management (mm) related command options

Show top memory contributors ("block list") in <allocator> sorted by used size descending

Generate output file with allocation stack trace information for <allocator>

Activation of allocator call stack trace for <allocator>

Particularly useful in case of suspected memory leaks so that you can understand from which modules the memory allocations are mainly performed

Can result in significant overhead and should only be activated for limited times

Deactivation of allocator call stack trace for <allocator>

Reset all previous measurements ("reset usage")

Generate report with top <num> call stacks recorded for <allocator>

Provide breakdown of Pool/PersistenceManager/PersistentSpace(0)/DefaultLPA/Page content based on page type, e.g.:

ConvIdxPage 256k Temp : 1 (262144 Byte)
ConvLeafPage 256k Temp : 130 (34078720 Byte)
TidCidMappingPage 256k Short : 1 (262144 Byte)
FileIDMappingPage 256k Temp : 172 (45088768 Byte)
FileIDMappingPage 256k Short : 2 (524288 Byte)
ContainerDirectoryPage 256k Short : 35 (9175040 Byte)
ContainerDirectoryPage 256k Long : 2 (524288 Byte)
ContainerNameDirectoryPage 256k Long : 1 (262144 Byte)
UndoFilePage 64k Short : 707 (46333952 Byte)
VirtualFilePage 4k InternalShort : 134 (548864 Byte)
VirtualFilePage 16k InternalShort : 57 (933888 Byte)
VirtualFilePage 64k InternalShort : 325 (21299200 Byte)
VirtualFilePage 256k InternalShort : 196 (51380224 Byte)
VirtualFilePage 1M InternalShort : 552 (578813952 Byte)
VirtualFilePage 4M InternalShort : 2832 (11878268928 Byte)
VirtualFilePage 16M InternalShort : 9458 (158678908928 Byte)
VarSizeEntryBasePage 256k Short : 809 (212074496 Byte)
...

Database snapshots can result in significantly increased disk space requirements, because the before image of modified blocks needs to be stored in addition to the normal data blocks. Therefore you should make sure that old snapshots are deleted. SQL: "HANA_IO_Snapshots" (SAP Note 1969700) can be used to check for old snapshots. See SAP Note 2100009 for more information related to savepoints and snapshots.

You can use the hdbcons command "snapshot a <snapshot_id>" (SAP Note 2222218) to find out how much disk space is allocated due to a snapshot. In the output you can find the relevant size information:

dropping this snapshot would free <num_pages> pages with total size of <size_MB> MB

See SAP Note 2100009 ("What are reasons for snapshots being retained for a long time?") for typical situations when snapshots exist for a long time.

Normal savepoints work in a similar way like database snapshots and all pages referenced by one savepoint are kept until the next savepoint succeeds. If a page is changed, both the former version and the new version needs to be stored in parallel. Normally this doesn't result in a significantly increased disk space, but in case of a low savepoint frequency (e.g. due to a very long running savepoint or due to a high setting of parameter global.ini -> [persistence] -> savepoint_interval_s) or in case of a high change load the persistence overhead can be significant. See SAP Note 2100009 for more information related to savepoints and snapshots.

In this scenario you can observe a rising amount of shadow pages and check ID 383 ("Max. size of shadow pages (GB, last day)") of the SAP HANA Mini Checks (SAP Note 1999993) can be reported as potentially critical.

As described in SAP Note 2014987 the disk size can remain at a high level after having performed a large DELETE or TRUNCATE operation. The amount of allocated disk space can be 16 MB * <num_columns> * <num_partitions> in the worst case.

Proceed as described in SAP Note 2014987 in order to reduce the allocated disk size.

Be aware that with SAP HANA <= 2.00.024.06 and <= 2.00.034 packed LOBs of column store tables are generally not purged after a TRUNCATE operation. You have to upgrade to a more recent SAP HANA Revision or recreate the table to purge the midsize LOBs successfully. See SAP Note 2707020 for more details.

Orphan disk LOBs can be responsible for a significant space allocation on disk that isn't reflected in the memory. See SAP Note 2220627 ("Can there be orphan disk LOBs?") for more information related to orphan disk LOBs.

In some scenarios, e.g. in context of smart data integration (SDI, SAP Note 2400022), virtual files are used that aren't related to tables. If they are loaded into memory, they are part of the SAP HANA page cache (Pool/PersistenceManager/PersistentSpace/DefaultLPA/Page) that will be unloaded early. The size on disk is typically significantly larger than the memory footprint.

You can use the following hdbcons command to determine the largest virtual files of a service (SAP Note 2222218):

hdbcons 'vf t'

Although this kind of space overhead doesn't properly fit here (because disk LOBs are never loaded into memory), it should be mentioned for completeness purposes.

LOBs are allocated with fix page sizes (>= 4 KB) and so there can be significant unused space, particularly if you have many small LOB values smaller than 4 KB. See SAP Note 2220627 for more information related to LOBs. You can use SQL: "HANA_LOBs_LOBFiles" (SAP Note 1969700) in order to check for allocated LOB space (PHYS_SIZE_MB) and used LOB space (BIN_SIZE_MB).

Due to the fact that the full pages are backed up, the backup size can be significantly larger than the used disk size in some cases.

If you see a steady size increase, it can be caused by a memory leak, e.g.:

• SAP Note 2062555 (join operation in the subquery of an UPDATE statement, fixed with Rev. >= 1.00.83)
• SAP Note 2088349 (querying calculation views with currency conversion, fixed with Rev. >= 1.00.84)
• SAP Note 2789785 (memory leak when calling virtual procedure in SDI, fixed with Rev. >= 1.00.122.25)

If you suspect a memory leak that is not documented, yet, open a SAP incident on component HAN-DB in order to request a more detailed analysis.

Normally the statement specific heap allocators should be relased as soon as the database request ends. Due to SAP HANA bugs it can happen that the cleanup isn't performed if certain references (like temporary tables) still exist. You can check if you suffer from this scenario by clearing the SQL cache globally or some suspicious entries individually. See SAP Note 2124112 ("How can entries in the SQL cache be invalidated or reparsed manually?") for more information.

Attention: Clearing the SQL cache results in additional parsing requirements and so temporary performance regressions are possible.

The following already known scenarios exist:

• SAP Note 2312976 (DML operations, problem exists for Rev. 1.00.100 - 1.00.102.06 and 1.00.110 - 1.00.112.01)
• SAP Note 2312983 (memory leak in Pool/parallel/aggregates when querying on distributed environment with SAP HANA 1.00.100 - 1.00.102.06 and 1.00.110 - 1.00.112.02)
• SAP Note 2533352 (no proper cleanup after execution, fixed with SAP HANA >= 1.00.122.13, >= 2.00.012.02 and >= 2.00.021)
• SAP Note 2535110 (Memory Leak on Pool/parallel/compactcol and Pool/parallel/aggregates or Pool/itab with SAP HANA <= 1.00.122.12, <= 2.00.012.01 and 2.00.020)

If the size of statement allocators reduces significantly after clearing the SQL cache, you can use this approach as a workaround and additionally open a SAP incident on component HAN-DB in order to request a fix for this behavior.

The following scenarios can be responsible for an incomplete cleanup in case of terminations:

• SAP HANA Revisions <= 1.00.122.12, <= 2.00.002.02, <= 2.00.012.01 and 2.00.020 can suffer from an increase in Pool/itab in context of INSERT abortions (SAP Note 2535110).
• With SAP HANA <= 1.00.122.15 the smart data access (SDA, SAP Note 2180119) related internal procedure SDA_SELECT_AS_ITAB_DEV isn't OOM safe and so memory can remain allocated after an out-of-memory situation.
• With SAP HANA <= 1.00.122.15, <= 2.00.012.04 and <= 2.00.24 an OOM termination can result in an incomplete cleanup of memory allocations of distributed queries (SAP Note 2612022).

In BW environments the high utilization can be linked to temporary objects. In this case you can run report RSDDTMPTAB_DELETE to drop these temporary objects in order to check if it has a positive impact on the Pool/itab size (SAP Note 2352541). Be aware that running this report can result in terminations of currently running reports.

If the allocator size is large in context of planning engine activities, you can check if dropping no longer required planning sessions can help to reduce the allocations (SAP Note 2169283 -> "How can garbage collection be triggered manually?" -> "Planning engine garbage collection").

SAP Note 2583148 describes a problem with missing garbage collection in context of the TMA application.

If you execute MDX queries (e.g. using SAP HANA Studio), make sure that you explicitly close MDX requests (MDX CLOSE REQUEST <guid>) when you no longer need them. A COMMIT will not automatically close the requests.

If you suspect orphan MDX queries (e.g. because MDX CLOSE REQUEST wasn't executed), you can check for MDX related temporary tables in M_TEMPORARY_TABLES (MDX_..._<guid>). By dropping these tables (DROP TABLE _SYS_BIC.MDX_..._<guid>) also the related internal tables should be dropped. Only drop these tables if you are sure that they are no longer required.

If BPC reports are executed on the system, the results may not be closed properly in context of ENABLE_HANA_MDX = 'X' (SAP Note 2108247).

If you use smart data access (SAP Note 2180119) with Rev. <= 1.00.85.02 or Rev. 1.00.90 - 1.00.91, a SAP HANA bug can be responsible for growing Pool/itab requirements. Upgrade to a more recent SAP HANA Revision in order to resolve the problem. See SAP Note 2242507 for more information.

The tables (including indexes and LOBs) with the highest possible maximum memory consumption are shown. The maximum memory information is independent of the currently loaded columns and so it provides a general overview independent of the current load state.

hdbcons 'mm gc -f'

2222218

This command triggers an immediate garbage collection. Defragmentation will happen as much as possible.

Attention: Executing this command has potentially critical side-effects like a temporary blockage of business operations, a reduction of address space or - in the long run - increased memory fragmentation. Therefore it must only be executed when advised by SAP support.

global.ini -> [memorymanager] -> gc_unused_memory_threshold_abs
global.ini -> [memorymanager] -> gc_unused_memory_threshold_rel

2169283

These parameters trigger a garbage collection when both the absolute and relative value is exceeded. As soon as one of the configured limits is reached, memory garbage collection stops.

Attention: Setting these parameters can result in frequently recurring memory defragmentation activities and related performance regressions. If at all, you should set these parameters only temporarily (e.g. for a few minutes) during a less critical time frame. Unsetting the parameters will not stop the initial defragmentation.

At runtime of a memory garbage collection SAP HANA internal lock contention can result in reduced performance and increased resource consumption.

In busy systems contention and spin locks on operating system side are possible when releasing memory back to the operating system. This scenario results in increased system CPU consumption and page faults. As a workaround the following parameter can be set in order to execute the defragmentation sequentially:

indexserver.ini -> [memorymanager] -> disabled_parallel_tasks = poolgarbagecollection

Check if the available memory is exhausted on operating system side, e.g. because of external software allocating a lot of memory, large caches or another SAP HANA instance. Make sure that in the future there is always enough physical memory available to host the complete SAP HANA allocation limit.

See "Which indications exist that an OOM situation is triggered by the operating system?" below for more details.

global.ini -> [multidb] -> systemdb_reserved_memory

In SQLDBC / ODBC environments memory issues are reported with errors like:

SQL error -9300: no more memory
SQL error -10760: Memory allocation failed

There can be ABAP short dumps like DBSQL_ALLOCATION_FAILED, DBSQL_DBSL_NO_MEMORY or DBSQL_NO_PERM_MM_MEMORY for similar reasons.

The following errors indicate a lack of memory in the data provisioning agent (dpagent):

GC overhead limit exceeded (max heap: <heap_mb> MB)
Java heap space (failed to allocate <bytes> bytes) (max heap: <heap_mb> MB)

The amount of available memory can be adjusted in the dpagent parameter file dpagent.ini via -Xmx switch. See SAP Notes 2399187 and 2737656 for more information.

The following errors indicate a lack of memory in SAP HANA Studio:

GC overhead limit exceeded (max heap: <heap_mb> MB)
Insufficient memory for visualization

The amount of available memory can be adjusted in the SAP HANA Studio parameter file hdbstudio.ini via -Xmx and -Xms switches. See SAP Note 2159510 for more details.

[MEMORY_OOM] section in OOM dump:

• Sum of AB (allocated byte) significantly smaller than GLOBAL_MAX_ALLOCATION_LIMIT
• "--- precharge ok ---" entries in "Out of memory reasons" overview
• "Could not return <bytes>b to operating system.
  This is a configuration problem of your operating system:
  Please increase /proc/sys/vm/max_map_count"

Other information in OOM dump:

• Rather small value for /proc/sys/vm/max_map_count (SAP Note 1980196)
• Value smaller than 100 for SOFTVIRTUALLIMIT in /etc/sysconfig/ulimit in combination with an installed ulimit.rpm package ("rpm -qa | grep ulimit")

If the sum of allocated memory is smaller than the SAP HANA global allocation limit (and the amount of requested memory is not extraordinary large), the OOM is normally triggered from outside of SAP HANA. In this case you may also see "--- precharge ok ---" information in the OOM dump.

Reasons can be:

• Ulimit memory limitation (e.g. due to installed ulimit.rpm package or because of explicit configuration)
• Inadequate /proc/sys/vm/max_map_count setting (SAP Note 1980196)
• High soft ulimit setting for stack (SAP Note 2488924)
• Insufficient physical memory (e.g. due to inadequate SAP HANA memory settings or external software consuming a lot of memory)
• Address space limit reached (Intel: 128 TB, Power: 16 TB, Power with bigmem: 64 TB); make sure that bigmem flavor is used with Power on SLES 11.x; on SLES >= 12 bigmem is already default
• Wrong shared memory size information provided by OS for IBM on Power environments (SAP Note 2686011)

/var/log/messages contains messages like:

• <process> invoked oom-killer
• Out of memory: Kill process <pid> (hdbindexserver) score <score> or sacrifice child

Shared Memory

(allocators Pool/RowStoreTables/* aren't persisted)

columns of tables with unload priorities 6 to 9

global.ini -> [memoryobjects] -> disposition_weight_early_unload

 100

global.ini -> [memoryobjects] -> disposition_paged_attribute

 SAP HANA page cache
Hierarchy cache

global.ini -> [memoryobjects] -> disposition_weight_short_term

lob read
lob read small
lob write
lob write small

disk LOBs

indexserver.ini -> [persistence] -> disposition_lob_read
indexserver.ini -> [persistence] -> disposition_lob_read_small
indexserver.ini -> [persistence] -> disposition_lob_write
indexserver.ini -> [persistence] -> disposition_lob_write_small

global.ini -> [memoryobjects] -> disposition_weight_mid_term

 columns of tables with unload priorities 1 to 5
liveCache OMS versions having exceeded min_version_retention_time (SAP Note 2593571)

global.ini -> [memoryobjects] -> disposition_weight_long_term

 columns of tables with unload priority 0
row store
liveCache OMS versions not having reached min_version_retention_time (SAP Note 2593571)
main storages in persistent memory (SAP Note 2700084)

Memory information for granular units like connection and SQL statement are tracked in M_CONTEXT_MEMORY. It can be evaluated via SQL: "HANA_Memory_ContextMemory" (SAP  Note 1969700). This information tells you how much statement execution specific memory is currently allocated. This information is usually precise and it is used as basis of memory features like the statement memory limit. The following exceptions exist:

• SAP Note 2593571 (SAP HANA <= 1.00.122.13, <= 2.00.012.02, <= 2.00.021): Wrong implicit memory booking behavior in context of liveCache procedure calls 
• SAP Note 2603589 (SAP HANA <= 1.00.122.13, <= 2.00.012.02, <= 2.00.022): Allocations in orawstream::reserve are not properly deallocated from context memory.
• SAP Note 2584388 (SAP HANA <= 1.00.122.14): SQL cache related memory allocations may be accounted for the context memory and so statistics server calls (SAP Note 2147247) can show a high context memory size although at the same time the actual intermediate memory allocation is rather small.
• SAP Note 2628153 (SAP HANA 1.00.122.16): A wrong memory accounting can result in rising context memory values.
• SAP Note 2669798 (SAP HANA <= 1.00.122.17): Wrong memory accounting in context of MDS (SAP Note 2670064)
• SAP HANA <= 2.00.024.02, 2.00.030: Wrong accounting in config::IniParser::parse

In the worst case the wrong context memory allocation can result in statement memory limit terminations. As a workaround you can set the statement_memory_limit parameter sufficiently high to make sure that it isn't reached by the erroneous context memory value.

An implicit memory booking leak can also result in unjustified tracing of database requests as expensive statements if the memory threshold (global.ini -> [expensive_statement] -> threshold_memory) is configured and exceeded by the implicit memory booking (SAP Note 2180165).

Existing increased bookings can be cleaned by terminating the related connection (SAP Note 2092196). In case of statistics server sessions a restart is possible based on the description in SAP Note 2584388.

2180165

With SAP HANA <= 1.00.122.13, <= 2.00.012.01, <= 2.00.020 the memory value is incomplete and it is not reliable. With later Revisions it represents the highest memory utilization in an involved service.

With SAP HANA <= 1.00.122.21, <= 2.00.024.06 and <= 2.00.034 erroneous -1 values can be reported in some cases (SAP Note 2706472).

2757696

With SAP HANA 2.00.020 - 2.00.024.09 and <= 2.00.037 the column USED_PHYSICAL_MEMORY can contain too large values.