This sets an upper limit on the amount of memory (virtual memory) that the server will allocate for in-memory tables and indexes on in-memory tables. In-memory tables includes Temporary Tables and Transient Tables, as well as persistent in-memory tables.

The limit may be specified in bytes, kilobytes (KB), megabytes (MB), or gigabytes (GB). For example:

Value 0 means “no limit”.

As a general rule, for servers with 1 GB or less memory, the maximum amount that you should allocate to in-memory tables is usually 30% - 70% of the system’s physical memory. The more memory the system has, the larger the percentage of it you may use for in-memory tables.

You can change this parameter with the command:

0

RW

Once you have set ImdbMemoryLimit, you may set this additional parameter to give you advance warning before you use up all of memory. This ImdbMemoryLowPercentage parameter allows you to indicate what percentage of memory you may use before the server starts limiting your ability to insert rows into in-memory tables, and so on. For example, if ImdbMemoryLimit is 1000MB and ImdbMemoryLowPercentage is 90 (percent), then the server will stop accepting inserts when you have used up 900 megabytes of memory for your in-memory tables.

Valid values are between 60 and 99 (percent).

90

RW

This parameter sets a warning limit for the IMDB memory size.

The warning limit is expressed as a percentage of the ImdbMemoryLimit parameter value. When the ImdbMemoryWarningPercentage limit is exceeded, a system event is given.

The ImdbMemoryWarningPercentage parameter value is automatically checked for consistency. It must be lower than the ImdbMemoryLimit parameter value.

80

RW

Typically, when the server needs to use locks to prevent concurrency conflicts, the server locks individual rows. This means that each user affects only those other users who want to use the same row(s). However, the more rows are locked, the more time the server must spend checking for conflicting locks.

In some cases, it is worthwhile to lock an entire table rather than a large number of the rows in that table.

When this parameter is set to yes, the lock level is escalated from row-level to table-level after a specified number of rows (in the same table) have been locked within the current transaction.

Lock escalation improves performance, but reduces concurrency, because it means that other users are temporarily unable to use the same table, even if they want to use different rows within that table.

See also the parameter LockEscalationLimit.

Possible values are yes and no.

no

RW/
Startup

If LockEscalationEnabled is set to yes, this parameter indicates how many rows must be locked (within a single table) before the server will escalate lock level from row-level to table-level. See LockEscalationEnabled for more details.

The value may be any number from 1 to 2,147,483,647 (2^32-1).

1000

RW/
Startup

The server uses a hash table (array) to store lock information. If the size of the array is remarkably underestimated the performance degrades. Too large hash table does not affect directly to the performance although it causes memory overhead. The LockHashSize determines the number of elements in hash table.

This information is needed when the server is using pessimistic concurrency control (locking). The server uses separate arrays for in-memory tables and disk-based tables. This parameter applies to in-memory tables.

In general, the more locks you need, the larger this array should be. However, it is difficult to calculate the number of locks that you need, so you may need to experiment to find the best value for your applications.

The value that you enter is the number of hash table entries. Each table entry has a size of one pointer (4 bytes in 32-bit architectures). Thus, for example, if you choose a hash table size of 1,000,000, then the amount of memory required is 4,000,000 bytes (assuming 32-bit pointers).

1000000

RW/
Startup

Maximum number of bytes stored in the free list of the MME private memory pool (private memory pool is private for each main-memory index).

If there is more free memory in the private pool, the extra memory is merged into global pools.

A value of 0 means immediate merge to global pool, which usually degrades performance but minimizes memory footprint. The default value of 100000 gives good performance with little memory overhead.

Maximum value is 10000000.

100000

RW/
Startup

The value of MaxCacheUsage limits the amount of D-table cache used while checkpointing M-tables. The value is expected to be given in bytes. Regardless of the value of the MaxCacheUsage at most half of the D-table cache (IndexFile.CacheSize) is used for checkpointing M-tables. Value MaxCacheUsage=0 sets the value unlimited, which means that the cache usage is IndexFile.CacheSize/2.

8MB

RW/
Startup

This parameter defines the maximum approximate size of a transaction in bytes.

Some MME transactions (for example, DELETE FROM <table>) might cause solidDB^® to allocate a lot of memory for the operation. This can lead to an out-of-memory situation where solidDB^® cannot allocate any more memory from the operating system, and performs an emergency exit. To prevent this, use this parameter to define the maximum approximate size (in bytes) for each MME transaction; when the transaction size exceeds the value set with this parameter, the transaction fails with the error SOLID Database error 16509: MME transaction maximum size exceeded.

Value 0 means unlimited.

o

RW

Memory pool scope.

Possible values are Global and Table.

If set to Global, memory pools are shared between all MME data.

If set to Table, only objects that belong to the same database table are allocated from a single memory segment. This ensures that dropping a whole table frees the memory segment back to operating system. Only unused memory segments can be returned back to the system. This setting may also prevent released memory being reused by other tables which may lead to increased memory usage depending on the use case.

When MME.MemoryPoolScope is set to Table, you can use the DESCRIBE <table> statement to view the memory consumption for the table. For example:

Global

RW/
Startup

Number of global memory pools.

Larger values might give better performance on multicore systems with certain load scenarios, but they also increase memory slack and therefore server process size.

Minimum value is 1, maximum value is 64.

Default value is equal to General.Multiprocessing level

See Description

RW/
Startup

When set to yes, at shutdown, the server releases the memory used by M-tables explicitly, rather than relying on the operating system to clean up all memory associated with this process. Some operating systems may require you to set this to yes to ensure that all memory is released.

The possible values are yes and no.

The factory value is no because shutting down the server is faster that way.

no

RW/
Startup

This parameter defines the maximum number of threads used while restoring in-memory database during database startup. If you do not set this parameter explicitly, the value of this parameter is set to the same value as General.MultiprocessingLevel.

Possible values are between 1 and 65536. Value 1 means that the load is executed in single thread.

With invalid values, this parameter defaults to the value of General.MultiprocessingLevel.

In-memory database restore assigns one thread per each table if the number of tables is smaller or equal to the number of the parameter value.

Maximal concurrency is reached when the parameter value is smaller than the following two values: number of cores/processors, and the number of tables in the database.

Same as General.

Multiprocessing

Level

RW/
Startup