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, or 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.
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 initialized. 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, as well as offline, online, or recovery mode. 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:
For information on monitoring dbspaces, refer to Monitoring the Database Server for Disabling I/O Errors.
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: 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, refer to the onstat -F option in the utilities chapter of the IBM Informix: 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: 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 cleaner thread, and one or more 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.
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: 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: 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: 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 INFORMIXSTACKSIZE overrides 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.
When a session executes an SQL statement that requires access to a system catalog table, the database server reads the system catalog tables and stores them in structures that it can access more efficiently. These structures are created in the virtual portion of shared memory for use by all sessions. These structures constitute the dictionary cache.
You can configure the size of the dictionary cache with the DD_HASHSIZE and DD_HASHMAX configuration parameters. For more information about these parameters, refer to the chapter on configuration effects on memory in your IBM Informix: Performance Guide.
The following database operations can use large amounts of the virtual portion of shared memory to sort data:
The amount of virtual shared memory that the database server allocates for a sort depends on the number of rows to be sorted and the size of the row, along with other factors.
For information on parallel sorts, refer to your IBM Informix: Performance Guide.
When a session needs to access an SPL routine for the first time, the database server reads the definition from the system catalog tables and stores the definition in a cache. The database server converts the SPL routine to executable format and stores the routine in the cache, where it can be accessed by any session.
You can configure the size of the SPL routine cache with the PC_HASHSIZE and PC_POOLSIZE configuration parameters. For information about changing the default size of the SPL routine cache, refer to the chapter on queries and the query optimizer in your IBM Informix: Performance Guide.
The global pool stores structures that are global to the database server. For example, the global pool contains the message queues where poll threads for network communications deposit messages from clients. The sqlexec threads pick up the messages from the global pool and process them.
Home | [ Top of Page | Previous Page | Next Page | Contents | Index ]