|
[MME]
|
Description
|
Factory value
|
Access mode
|
|---|---|---|---|
|
ImdbMemoryLimit
|
Maximum amount of virtual memory (in bytes) that can be allocated to in-memory tables (including temporary tables and transient tables) and the indexes on those in-memory tables.
Follow the value with K (to specify a value in KB), M (to specify a value in MB), or G (to specify a value in GB). For example: ImdbMemoryLimit=1G
A value of 0 means "no limit". You should not use this default value; instead, set the parameter to a value that ensures that the in-memory data fits entirely within physical memory. Consider the following factors:
▪ The amount of physical memory in the computer.
▪ The amount of memory used by the operating system.
▪ The amount of memory used by solidDB (the program itself).
▪ The amount of memory set aside for the solidDB server cache (the IndexFile.CacheSize configuration parameter).
▪ The amount of memory required by the connections, transactions and statements running concurrently in the server. Typically, you should allocate at least 0.5 MB of memory for each client connection in the server.
▪ The memory used by other processes (programs and data) that are running in the computer.
When 100% of the memory that is specified by ImdbMemoryLimit is reached, the server prohibits UPDATE operations on in-memory tables. Before the limit is reached, the server prohibits the creation of new in-memory tables and INSERT operations on those tables.
As a general rule, for servers with 1 GB or less memory, the maximum amount that you should allocate to in-memory tables is 30% - 70% of the system physical memory.
Note This parameter applies to only solidDB main memory engine tables. It does not apply to disk-based tables.
You can only increase (not decrease) this value while the server is running.
For guidance on troubleshooting ImdbMemoryLimit see Troubleshooting MME.ImdbMemoryLimit.
|
0
|
RW
|
|
ImdbMemoryLowPercentage
|
Percentage of the virtual memory (configured in the MME.ImdbMemoryLimit parameter) that can be allocated to in-memory tables before the server starts limiting activities in order to prevent memory consumption from continuing to grow.
For example, if MME.ImdbMemoryLimit is 1000MB and MME.ImdbMemoryLowPercentage is 90%, the server limits activities if the memory allocated to the in-memory tables exceeds 900 megabytes. Specifically, the server:
▪ Prohibits further creation of in-memory tables (including temporary tables and transient tables) and indexes on in-memory tables.
▪ Prohibits INSERTs into in-memory tables.
Valid values range between 60 - 99 (percent).
Note This parameter applies to only solidDB main memory engine tables.
|
90
|
RW
|
|
ImdbMemoryWarningPercentage
|
Warning limit (as a percentage) 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 generated.
The ImdbMemoryWarningPercentage parameter value is automatically checked for consistency. It must be lower than the ImdbMemoryLimit parameter value.
Note This parameter applies to only solidDB main memory engine tables. It does not apply to disk-based tables.
|
80
|
RW
|
|
LockEscalationEnabled
|
If 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, see LockEscalationLimit.
Typically, when the server needs to use locks to prevent concurrency conflicts, the server locks individual rows. This means that each user affects only other users who want to use the same row(s). However, the more rows that 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 the table.
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.
Note This parameter applies to in-memory tables only.
|
no
|
RW/
Startup |
|
LockEscalationLimit
|
Number of rows that must be locked (within a single table) before the server escalates the lock level from row-level to table-level (only has effect if LockEscalationEnabled is set to yes). See LockEscalationEnabled for more details.
The value can be any number from 1 to 2147483647 (2^32-1).
Note This parameter applies to in-memory tables only.
|
1000
|
RW/
Startup |
|
LockHashSize
|
Number of entries in the hash table.
The server uses a hash table (array) to store lock information. If the size of the array is greatly underestimated the performance degrades. Too large a hash table does not directly affect the performance although it causes memory overhead.
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 might need to experiment to find the best value for your applications.
Each hash 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 |
|
LongRowMaxLimit
|
M-table maximum row length (in bytes).
Follow the value with K (to specify a value in KB) or M (to specify a value in MB).
Maximum value is 32M (32 MB).
|
10M
(10 MB) |
RW
|
|
LongRowsEnabled
|
If set to yes, M-table row length can exceed database block size.
|
yes
|
RO
|
|
MaxBytesCachedInPrivateMemoryPool
|
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. Maximum value is 10000000, while the default value of 100000 gives good performance with little memory overhead.
|
100000
|
RW/
Startup |
|
MaxCacheUsage
|
Maximum amount of D-table cache (in bytes) that can be used while checkpointing M-tables.
Follow the value with K (to specify a value in KB), M (to specify a value in MB), or G (to specify a value in GB).
Regardless of the value of MaxCacheUsage, at most half of the D-table cache (IndexFile.CacheSize) is used for checkpointing M-tables. Setting MaxCacheUsage=0 sets the value to unlimited, which means that the cache usage is IndexFile.CacheSize/2.
|
8M (8MB)
|
RW/
Startup |
|
MaxTransactionSize
|
Maximum size (in bytes) of a transaction.
Follow the value with K (to specify a value in KB), M (to specify a value in MB, or G (to specify a value in GB).
For example: MME.MaxTransactionSize=100M
Some MME transactions (for example, DELETE FROM table_name) 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 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.
A value of 0 means unlimited.
|
0
|
RW
|
|
MemoryPoolScope
|
Memory pool scope.
Possible values are Global and Table.
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 system. MemoryPoolScope Table may also prevent released memory being reused by other tables which may lead to increased memory usage depending on the use case.
If set to Global, memory pools are shared between all MME data.
When MME.MemoryPoolScope is set to Table, you can use the DESCRIBE statement to view the memory consumption for the table. For example:
DESCRIBE tmemlimit_tab;
RESULT Catalog: DBA Schema: DBA Table: TMEMLIMIT_TAB Table type: in-memory Memory usage: 7935 KB (total), 7925 KB (active), 6192 KB (rows), 1733 KB (indexes). ... 1 rows fetched. |
Global
|
RW/
Startup |
|
NumberOfMemoryPools
|
Bigger values might give better performance on multicore systems with certain load scenarios but they also increase memory slack and hence server process size.
Minimum value is 1, maximum value is 64.
Default value equals to General.Multiprocessinglevel
Maximum value: 64
Defaults = to General.Multiprocessinglevel
|
See Description
|
RW/
Startup |
|
ReleaseMemoryAtShutdown
|
If 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 might require you to set this to yes to ensure that all memory is released.
The default value is no because shutting down the server is faster that way.
|
no
|
RW/
Startup |
|
RestoreThreads
|
Maximum number of threads to use while restoring an in-memory database during database startup.
Possible values are between 1 and 65536. A value of 1 means that the load is executed in single thread.
If the value entered is invalid, this parameter defaults to the value of General.MultiprocessingLevel.
An in-memory database restore assigns one thread for each table if the number of tables is smaller or equal to the parameter value.
Maximum 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.MultiprocessingLevel
|
RW/
Startup |