Controlling process size

The process size does not correspond directly to the actual database memory consumption, because the process size contains also non-database elements. The following aspects affect the process size:

▪Cache size: The factory value is 32 MB. You can control the database cache size with the IndexFile.CacheSize parameter.

▪Executable program footprint: The footprint approximately 5 MB, but as different libraries are initializes, the footprint can grow up to 10 MB (varies per platform and release).

▪Client threads: Each client consumes a few hundred kilobytes of main memory.

▪Dynamic memory reserved for command handling: Server allocates resources for execution plans, temporary data, and so on.

▪Statement cache: When the server executes SQL statements, it parses and optimizes them first. This can be time consuming. The server can store the parsed and optimized statements in the virtual memory. The virtual memory allocation is called the statement cache. You can control the statement cache with ODBC and JDBC connection properties.

▪The hash table for the transaction lookup table: The General.LockHashSize and MME.LockHashSize parameters affect the memory consumption. They define the number of elements in the lock hash table.

▪Transaction and sort buffers

▪Accessed tables that are buffered in the main memory

You can control and monitor the process size by using configuration parameters and ADMIN COMMAND commands. Any violations of process limits you might have set are logged in the solmsg.out log file.

The ADMIN COMMAND 'info processsize'; command returns the current amount of memory that the in-memory database process uses. The value returned is a VARCHAR, and it indicates the number of kilobytes used by the process. Note that this returns the amount of virtual memory used, not the amount of physical memory used.

The Srv.ProcessMemoryLimit parameter specifies the maximum amount of virtual memory that can be allocated to the in-memory database process.

The factory value for Srv.ProcessMemoryLimit is 0; there is no process memory limit. If you use the parameter, set it to a value that will ensure that the in-memory database process will fit entirely within physical memory. The following factors impact the amount of memory needed:

▪the amount of physical memory in the computer

▪the amount of memory used by the operating system

▪the amount of memory used by in-memory tables (including temporary tables and transient tables) and the indexes on those in-memory tables

▪the amount of memory set aside for the solidDB^® server’s cache (the IndexFile.CacheSize parameter)

▪the amount of memory required by the connections, transactions and statements running concurrently in the server. The more concurrent connections and active statements there are in the server, the more working memory the server requires. 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 the limit is reached, that is, when the in-memory database process uses up 100% of the memory specified by Srv.ProcessMemoryLimit, the server will accept ADMIN COMMANDs only. You can use the Srv.ProcessMemoryWarningPercentage and Srv.ProcessMemoryLowPercentage parameters to warn you about increasing process memory consumption.

▪The Srv.ProcessMemoryLimit and Srv.ProcessMemoryCheckInterval parameters are interlinked; if the ProcessMemoryCheckInterval parameter is set to 0, the ProcessMemoryLimit parameter is not effective, that is, there is no process memory limit.

▪You should not set the Srv.ProcessMemoryLimit parameter when using SMA. If you need to limit the memory the SMA server uses, use the SharedMemoryAccess.MaxSharedMemorySize parameter.

The Srv.ProcessMemoryLowPercentage parameter sets a warning limit for the total process size. The limit is expressed as percentage of the Srv.ProcessMemoryLimit parameter value.

Prior to exceeding the limit, you have exceeded the warning limit defined with the ProcessMemoryWarningPercentage parameter and received a warning in the solmsg.out log file. When the Srv.ProcessMemoryLowPercentage limit is exceeded, a system event is given.

The limit set with Srv.ProcessMemoryLowPercentage must be higher than the Srv.ProcessMemoryWarningPercentage limit. For example, if the Srv.ProcessMemoryWarningPercentage is set to 82, the Srv.ProcessMemoryLowPercentage value must be at least 83.

The Srv.ProcessMemoryWarningPercentage parameter sets the first warning limit for the total process size. The warning limit is expressed as percentage of the Srv.ProcessMemoryLimit parameter value.

When the Srv.ProcessMemoryWarningPercentage limit is exceeded, a system event is given in the solmsg.out log file.

The limit set with Srv.ProcessMemoryWarningPercentage must be lower than the Srv.ProcessMemoryLowPercentage limit.

The Srv.ProcessMemoryCheckInterval parameter defines the interval for checking the process size limits. The interval is given in milliseconds.

The minimum non-zero value for Srv.ProcessMemoryCheckInterval is 1000 (ms). Only values 0, 1000, or above 1000 (1 second) are allowed. If the given value is above 0 but below 1000, an error message is given.

The factory value is 0, that is, the process size checking is disabled.

The Srv.ProcessMemoryLimit and Srv.ProcessMemoryCheckInterval parameters are interlinked; if the ProcessMemoryCheckInterval parameter is set to 0, the ProcessMemoryLimit parameter is not effective, that is, there is no process memory limit.