The virtual portion of shared memory stores the following data:
The database server shared memory contains seven internal tables that track shared-memory resources. The shared-memory internal tables are as follows:
The buffer table tracks the addresses and status of the individual buffers in the shared-memory pool. When a buffer is used, it contains an image of a data or index page from disk. For more information on the purpose and content of a disk page, refer to Pages.
Each buffer in the buffer table contains the following control information, which is needed for buffer management:
Buffer status is described as empty, unmodified, or modified. An unmodified buffer contains data, but the data can be overwritten. A modified (dirty) buffer contains data that must be written to disk before it can be overwritten.
Buffers receive lock-access levels depending on the type of operation that the user thread is executing. The database server supports two buffer lock-access levels: shared and exclusive.
Each buffer header maintains a list of the threads that are waiting for the buffer and the lock-access level that each waiting thread requires.
Each database server buffer has one entry in the buffer table.
For information on the database server buffers, refer to Resident Portion of Shared Memory. For information on how to monitor the buffers, refer to Monitoring Buffers.
The database server determines the number of entries in the buffer-table hash table, based on the number of allocated buffers. The maximum number of hash values is the largest power of 2 that is less than the value of buffers, which is specified in one of the BUFFERPOOL configuration parameter fields.
The chunk table tracks all chunks in the database server. If mirroring has been enabled, a corresponding mirror chunk table is also created when shared memory is set up. The mirror chunk table tracks all mirror chunks.
The chunk table in shared memory contains information that enables the database server to locate chunks on disk. This information includes the number of the initial chunk and the number of the next chunk in the dbspace. Flags also describe chunk status: mirror or primary; offline, online, or recovery mode; and whether this chunk is part of a blobspace. For information on monitoring chunks, refer to Monitoring Chunks.
The maximum number of entries in the chunk table might be limited by the maximum number of file descriptors that your operating system allows per process. You can usually specify the number of file descriptors per process with an operating-system kernel-configuration parameter. For details, consult your operating-system manuals.
The dbspace table tracks storage spaces in the database server. The dbspace-table information includes the following information about each dbspace:
If the storage space is a blobspace, flags indicate the media where the blobspace is located: magnetic, removable, or optical media. If the storage space is an sbspace, it contains internal tables that track metadata for smart large objects and large contiguous blocks of pages containing user data.
For information on monitoring dbspaces, refer to Monitoring Disk Usage.
The page-cleaner table tracks the state and location of each of the page-cleaner threads. The number of page-cleaner threads is specified by the CLEANERS configuration parameter in the ONCONFIG file. For advice on how many page-cleaner threads to specify, refer to the chapter on configuration parameters in the IBM Informix Dynamic Server Administrator's Reference.
The page-cleaner table always contains 128 entries, regardless of the number of page-cleaner threads specified by the CLEANERS parameter in the ONCONFIG file.
For information on monitoring the activity of page-cleaner threads, see information on the onstat -F option in the IBM Informix Dynamic Server Administrator's Reference.
The tblspace table tracks all active tblspaces in a database server instance. An active tblspace is one that is currently in use by a database session. Each active table accounts for one entry in the tblspace table. Active tblspaces include database tables, temporary tables, and internal control tables, such as system catalog tables. Each tblspace table entry includes header information about the tblspace, the tblspace name, and pointers to the tblspace tblspace in dbspaces on disk. (The shared-memory active tblspace table is different from the tblspace tblspace.) For information on monitoring tblspaces, refer to Monitoring Tblspaces and Extents.
The database server manages one tblspace table for each dbspace.
The transaction table tracks all transactions in the database server.
Tracking information derived from the transaction table appears in the onstat -x display. For an example of the output that onstat -x displays, refer to monitoring transactions in your IBM Informix Dynamic Server Performance Guide.
The database server automatically increases the number of entries in the transaction table, up to a maximum of 32,767, based on the number of current transactions.
For more information on transactions and the SQL statements that you use with transactions, refer to the IBM Informix Guide to SQL: Tutorial, the IBM Informix Guide to SQL: Reference, and the IBM Informix Guide to SQL: Syntax.
The transaction table also specifically supports the X/Open environment. Support for the X/Open environment requires TP/XA. For a description of a transaction in this environment, refer to the IBM Informix TP/XA Programmer's Manual.
The user table tracks all user threads and system threads. Each client session has one primary thread and zero-to-many secondary threads, depending on the level of parallelism specified. System threads include one to monitor and control checkpoints, one to process onmode commands, the B-tree scanner threads, and page-cleaner threads.
The database server increases the number of entries in the user table as needed. You can monitor user threads with the onstat -u command.
A big buffer is a single buffer that is made up of several pages. The actual number of pages is platform dependent. The database server allocates big buffers to improve performance on large reads and writes.
The database server uses a big buffer whenever it writes to disk multiple pages that are physically contiguous. For example, the database server tries to use a big buffer to perform a series of sequential reads (light scans) or to read into shared memory simple large objects that are stored in a dbspace.
Users do not have control over the big buffers. If the database server uses light scans, it allocates big buffers from shared memory.
For information on monitoring big buffers with the onstat command, refer to the chapter on configuration effects on I/O activity in your IBM Informix Dynamic Server Performance Guide.
When a client application requests a connection to the database server, the database server begins a session with the client and creates a data structure for the session in shared memory called the session-control block. The session-control block stores the session ID, the user ID, the process ID of the client, the name of the host computer, and various status flags.
The database server allocates memory for session data as needed.
When a client connects to the database server, in addition to starting a session, the database server starts a primary session thread and creates a thread-control block for it in shared memory.
The database server also starts internal threads on its own behalf and creates thread-control blocks for them. When the database server switches from running one thread to running another one (a context switch), it saves information about the thread— such as the register contents, program counter (address of the next instruction), and global pointers—in the thread-control block. For more information on the thread-control block and how it is used, refer to Context Switching.
The database server allocates memory for thread-control blocks as needed.
Each thread in the database server has its own stack area in the virtual portion of shared memory. For a description of how threads use stacks, refer to Stacks. For information on how to monitor the size of the stack for a session, refer to monitoring sessions and threads section in your IBM Informix Dynamic Server Performance Guide.
The size of the stack space for user threads is specified by the STACKSIZE parameter in the ONCONFIG file. The default size of the stack is 32 kilobytes. You can change the size of the stack for all user threads, if necessary, by changing the value of STACKSIZE. For information and a warning on setting the size of the stack, refer to STACKSIZE in the chapter on configuration parameters in the IBM Informix Dynamic Server Administrator's Reference.
To alter the size of the stack for the primary thread of a specific session, set the INFORMIXSTACKSIZE environment variable. The value of INFORMIXSTACKSIZEoverrides the value of STACKSIZE for a particular user. For information on how to override the stack size for a particular user, refer to the description of the INFORMIXSTACKSIZE environment variable in the IBM Informix Guide to SQL: Reference.
To more safely alter the size of stack space, use the INFORMIXSTACKSIZE environment variable rather than alter the configuration parameter STACKSIZE. The INFORMIXSTACKSIZE environment variable affects the stack space for only one user, and it is less likely to affect new client applications that initially were not measured.
Each thread has a heap to hold data structures that it creates while it is running. A heap is dynamically allocated when the thread is created. The size of the thread heap is not configurable.
Home | [ Top of Page | Previous Page | Next Page | Contents | Index ]