When you configure and initialize your database server, you set basic memory configuration parameters. This manual does not discuss each of the basic memory configuration parameters. Instead, where appropriate it discusses the way in which these parameters work with other memory-use parameters.
For information about these basic memory configuration parameters refer to your machine notes. If your machine notes do not provide guidelines for the following parameters, refer to the IBM Informix: Extended Parallel Server Administrator's Guide:
If your platform supports enforced residency for physical memory segments, set the RESIDENT configuration parameter to -1. The database server can then ensure that the resident portion of shared memory remains in physical memory to improve data read and write activity from the buffer cache.
The SHMTOTAL configuration parameter specifies the shared memory available to the database server. To prevent the database server from trying to allocate all physical memory for its own use when you enforce residency for shared memory, make sure that you set this configuration parameter to at least 85 megabytes less than total physical shared memory on each coserver. If the operating system cannot get the memory that it needs, the node hangs.
When the database server is online, you can turn residency on or off dynamically.
The virtual portion of shared memory holds session- and request-specific data as well as other information, as described inMemory Allocation. The SHMVIRTSIZE configuration parameter specifies the size of the virtual portion of shared memory that is initially allocated to the database server. The maximum size of a database server virtual shared-memory partition is 4 gigabytes. Refer to your machine notes for information about shared memory sizes for your platform.
Although the database server adds increments of shared memory to the virtual portion as needed to process large queries or handle peak loads, allocating additional shared memory increases time for transaction processing. Try to specify a virtual portion of shared memory large enough to process most normal workloads. For database servers that run OLTP applications, an initial setting might be the larger of the following values:
In the formula, connections is the number of connections for all network types that are specified by one or more NETTYPE parameters in the sqlhosts file. (The database server uses connections * 200 by default.)
To establish an appropriate value for the initial size of the virtual portion of shared memory, monitor memory use at intervals while the database server is under a normal workload. Include this information in the performance-history data that you collect.
To reduce the amount of shared memory that the database server needs to add dynamically, estimate the amount of stack space required for the average number of threads that your system runs. Then include that amount in the value you set for the initial amount of shared virtual memory. To estimate the amount of required stack space, use the following formula:
stacktotal = STACKSIZE * avg_no_of_threads
Depending on your workload, estimate between 60 and 70 percent of the total number of connections, as specified in the sqlhosts file or with NETTYPE configuration parameters. To determine the average number of threads more precisely, monitor the number of active threads at regular intervals to determine this amount. Use onstat -g sts to check the stack use of threads.
You might set the increment size for virtual-memory (SHMADD) based on the size of physical memory, as follows.
| Physical Memory on Each Coserver | SHMADD Value for Each Coserver |
|---|---|
| 256 megabytes or less | 8192 kilobytes (4 megabytes, the default) |
| Between 257 and 512 megabytes | 16,384 kilobytes (16 megabytes) |
| More than 512 megabytes | Up to 65,536 kilobytes (64 megabytes) |
The maximum allowable size of a virtual memory increment is 4 gigabytes on a 64-bit platform, 512 megabytes on a 32-bit platform.
If you start with the default recommendation for each shared memory increment, monitor the memory use of the database server under various loads to determine an appropriate number. Because the database server consumes CPU cycles when it adds shared memory, consider these tradeoffs:
The size of added memory segments should match the size of segments that the operating system allocates. Some operating systems place a lower limit on the size of a shared-memory segment; your setting for SHMADD should be more than this minimum. Refer to your machine notes for information about shared memory for your platform. For more information about configuring shared-memory, refer to Allocating Memory for DSS Queries.
Include shared-memory use data in the information that you collect in your performance history. To find out how many shared-memory segments the database server is currently using, use the onstat -g seg command on a specific coserver or use xctl onstat -g seg to display shared memory information for all coservers. The following example shows onstat-g seg output.
Segment Summary: id key addr size ovhd class blkused blkfree 13406 1382029314 c0b74000 155648 616 M 6 32 13805 1382029313 c1777000 13066240 9512 R* 3160 30 (shared) 1382029313 c23ed000 268447744 8804 V 10656 54883 Total: - 281669632 13822 54945
In Figure 5, size displays the number of bytes in the segment, blkused displays the number of blocks in the segment in page units, and blkfree displays the number of free blocks in the segment page units. To calculate the number of bytes in a segment, multiply the number of blocks by the page size that you specified in the PAGESIZE configuration parameter. The default page size is 4 kilobytes.