MATRIXX Engine Memory

Memory is allocated dynamically during runtime from the system's total shared memory pool to accommodate the growth of databases and other memory buffers. This allocation provides flexibility in sizing data, reduces the risk of running out of memory, and creates less wasted space.

Instead of each segment of each database using its own shared memory space, a single large shared memory pool is allocated at system start-up. This memory pool reflects the total amount of memory that holds all databases and shared memory buffers. All database segments and shared buffer segments are allocated from this pool. This alleviates the need to configure static memory parameters for each database and, instead, only requires the configuration of one parameter — the total available amount of all MATRIXX Engine memory. All databases can dynamically add segments as needed. You monitor the large and huge buffer and pools by using the print_blade_stats.py -P command.

MATRIXX Engine memory is stored as Relocatable Data Models (RDMs). An RDM instance can be memory mapped by multiple processes, making it accessible, and all objects within them can be looked up efficiently by a segment-offset pair. Segments are the rows in an RDM, and an offset is the instance of the entry within the segment. When an object is created, an RDM header is used and the usable size is allocated from one of the extended data segments. An RDM can be static or variable. Static RDMs store non-variable data and have a free queue associated with the segments to manage the objects in memory. The Statistics database is not shared and objects are not added or deleted, so the database uses a static RDM for more efficiency. The free queue tracks how many entries are available for new data creations by using a <low_water_mark> parameter value. When the number of entries in the free queue is less than this threshold value, new RDM segments are allocated proactively. Variable RDMs use extended data segments to store variable data associated with an object. All other MATRIXX databases use variable RDMs to allow the memory to be shared and reused once an object is changed or deleted, and memory is reclaimed. For variable RDMs, the <extended_data_low_water_mark_in_bytes> parameter value determines when another segment is allocated proactively. When the number of free bytes in all the extended segments is less than this threshold value, another segment is added to the RDM.

MATRIXX Engine uses dynamic hashing to locate data for access, insertion, and deletion, making database access much more efficient. To handle fragmentation of a data segment caused by the allocation, de-allocation, and changing of object sizes, a garbage collection task reclaims memory occupied by objects that are no longer in use. This internal memory management service ensures that allocated memory is returned to the available free memory pool. As objects in the database are deleted or moved because they increased in size, the empty spaces left behind are tagged for garbage collection. The garbage collection runs across the databases on a scheduled, configurable interval or if memory fragmentation gets too high. When garbage collection runs, the holes are merged into larger blocks and returned to the free memory pool.

The size of the reclaimable memory for variable RDM databases depends on the garbage collection configuration. To change the default memory defragmentation values, change the answer to the create_config.info question Do you want to use the default database garbage collection settings? and then set threshold values for the number of fragmentation holes and the garbage collection size for each database.

You can monitor database memory by using SNMP or the print_blade_stats.py -B command. The database statistics categories are in the following list. See the discussion about print_blade_stats.py for examples. See the discussion about MATRIXX MIB files for more information and the discussion about all MATRIXX SNMP statistics and traps for a complete list of MATRIXX Engine statistics:

Amount of memory allocated and in use.
Amount of memory that is allocated in a database segment.
Amount of memory that is free and available to be allocated.
Amount of database segments allocated as a percentage of the total allocation.
Average database growth rate (KB/sec) during the preceding minute, hour, and day for each database.
Amount of memory that is neither free nor allocated.
Number of allocation holes awaiting garbage collection.

In addition, notifications are sent based on the following thresholds, which determine when data segments are allocated proactively by MATRIXX Engine:

Amount of the system's shared memory that is allocated from the amount that is available for allocation.
Amount of a database's memory that is allocated from the total amount that is available for allocation to that database.

System administrators can change the default values of these thresholds by changing the answers to the following create_config.info file questions:

SNMP:What is the database memory percentage notification threshold?
SNMP:What is the system memory notification threshold in MB?

Note: MATRIXX databases and working buffers can assign memory only from the total system shared memory that is configured for a MATRIXX server. If this memory pool is depleted, it can only be reclaimed by restarting the server or adding memory to the server.

For information about how to change the default memory configuration, see the discussion about database sizing and memory configuration in MATRIXX Installation and Upgrade.