ImdbMemoryLimit

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:

A value of 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:

where n is a positive integer. You may only increase, not decrease, this value while the server is running. The command takes effect immediately. The new value is written back to the solid.ini file at shutdown.

Ensure that your in-memory tables will fit within the available physical memory. If you exceed the amount of physical memory available, performance will decrease significantly. If you use up all of the available virtual memory, the server will abruptly limit inserts, updates, and so on, and will return error codes.

0

RW

ImdbMemoryLow
Percentage

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

ImdbMemoryWarning
Percentage

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

LockEscalationEnabled

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

LockEscalationLimit

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

LockHashSize

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

MaxBytesCachedIn
PrivateMemoryPool

This parameter defines the maximum bytes stored into the free list of MME’s 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, usually degrades performance, but minimizes memory footprint. There is no maximum value; the default value of 100000 gives good performance with little memory overhead.

100000

RW/
Startup

MaxCacheUsage

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

MaxTransactionSize

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.

0

 

MemoryPoolScope

This parameter sets the memory pool scope. Possible values are Global and Table.

When set to Table, only objects that belong to the same database table are allocated from a single memory segment. This ensures, for example, that dropping a whole table frees the memory segment back to operating system. Only unused memory segments can be returned back to system.

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

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

 

NumberOfMemory
Pools

This parameter defines the number of global memory pools. Bigger values may give better performance on multicore systems with certain load scenarios but they also increase memory slack and hence server process size.

1

 

ReleaseMemoryAt
Shutdown

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

 

RestoreThreads

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.

Same as General.
MultiprocessingLevel