Memory

Informix likes large amounts of memory, there is no getting away from this fact.

As with CPU and disk, memory is only a problem if Informix or the server has insufficient for their needs. Informix likes significant quantities of memory and restricting the amount of memory available will nearly always have a detrimental effect on performance.

If there is not sufficient real memory available then the operating system will start paging to free up the memory that is required. When these pages that are needed by active processes must be paged back in, performance will be negatively affected. Paging, in itself, however is not necessarily a problem.

The buffer pool, which resides in the resident portion of the shared memory, is Online's largest memory user. Allocating a third or even half the total memory available to the buffer pool is not unusual in OLTP applications. If the application uses a large number of Stored Procedures then the cache used to store the Stored Procedures can grow very quickly. In the later versions this cache can be tuned.

When a user session is started the session receives a session pool which is identified by the session id. The size of this pool depends on the activity of the session.

A new session receives a session pool ie memory. The session pool is named by the session-id. The size of the session pool increases depending upon the activity. What the user requests has a direct effect on the memory required, any query that sorts or uses a hash join needs more memory. PDQ also requires memory for light scans and any intermediate files.

Types of Shared Memory

Within Online shared memory is divided into three distinct type.

Resident	The system information and buffer cache is held in the resident portion of shared memory. In general for OLTP applications the performance will increase if the numbers of buffers are increased. This is not always the case in DSS situations when tables are often sequentially scanned and these queries can flood the buffer cache. Therefore, in DSS applications increasing the resident portion might not make the best use of the memory available.
Virtual	The memory that is used by the various sessions and threads are held in pools that reside in the virtual portion of shared memory. OLTP applications do use the virtual areas but in these situations a significant amount of memory required. However, in DSS applications the session, thread and sort pools are used heavily and increasing the size of the virtual area will improve performance.
Message	This portion is not configurable and contains the message buffers that are used to communicate between the server and the clients when the connection is made via shared memory connections.

Misconfiguring or under configuring the kernel will adversely the instance's performance, the two most common areas with respect to Informix are the shared memory and semaphore parameters. Two key parameters are

SHMMAX	This value set the maximum size a shared memory segment can be. It is more efficient to use one larger segment as opposed to a number of small segments. Some Unix's limit the number of segments that can be allocated to a process eg AIX
SHMSEG	This value specificies the maximum number of segments that a process can have. DSS queries uses large amounts of memory, to accommodate this Online allocates memory from the virtual area of shared memory. As the memory increases more segments must be requested. Some Unix's limit the number of segments that can be allocated to a process eg AIX

It is unusual to find a 'standard' kernel configuration of any Unix that is correct for Informix - something always needs to be changed.

OLTP and DSS and Memory

For OLTP environments allocate as large a resident portion as is possible, i.e. increase the number of BUFFERS, and the system will usually will perform better. Use onstat -p to monitor percent cached and adjust BUFFERS upward until the percent cached remains stable.

For DSS only environments allocate the use of all of the virtual portion to your decision support queries. The maximum amount of memory that can be allocated using the configuration parameter is

DS_TOTAL_MEMORY= SHMTOTAL / 2

But this can be dynamically overriden by using the onmode utility command: onmode -M kbytes

If the system must support DSS and OLTP applications then the DS_TOTAL_MEMORY configuration parameter should be used to limit the virtual shared memory available for decision support queries. After monitoring the OLTP usage of the virtual portion it appears the the virtual portion is not being full utilised then increase DS_TOTAL_MEMORY.