The following classes of virtual processors perform disk I/O:
The PIO class performs all I/O to the physical-log file, and the LIO class performs all I/O to the logical-log files, unless those files reside in raw disk space and the database server has implemented kernel-asynchronous I/O.
On operating systems that do not support kernel-asynchronous I/O, the database server uses the AIO class of virtual processors to perform database I/O that is not related to physical or logical logging.
The database server uses the CPU class to perform kernel-asynchronous I/O (KAIO) when it is available on a platform. If the database server implements kernel-asynchronous I/O, a KAIO thread performs all I/O to raw disk space, including I/O to the physical and logical logs.
To find out if your platform supports kernel-asynchronous I/O, refer to the machine notes file.
For more information about nonlogging I/O, refer to Asynchronous I/O.
In general, the database server prioritizes disk I/O by assigning different types of I/O to different classes of virtual processors and by assigning priorities to the nonlogging I/O queues. Prioritizing ensures that a high-priority log I/O, for example, is never queued behind a write to a temporary file, which has a low priority. The database server prioritizes the different types of disk I/O that it performs, as Table 12 shows.
| Priority | Type of I/O | VP Class |
|---|---|---|
| 1st | Logical-log I/O | CPU or LIO |
| 2nd | Physical-log I/O | CPU or PIO |
| 3rd | Database I/O | CPU or AIO |
| 3rd | Page-cleaning I/O | CPU or AIO |
| 3rd | Read-ahead I/O | CPU or AIO |
The LIO class of virtual processors performs I/O to the logical-log files in the following cases:
Only when kernel asynchronous I/O is implemented and the logical-log files are in raw disk space does the database server use a KAIO thread in the CPU virtual processor to perform I/O to the logical log.
The logical-log files store the data that enables the database server to roll back transactions and recover from system failures. I/O to the logical-log files is the highest priority disk I/O that the database server performs.
If the logical-log files are in a dbspace that is not mirrored, the database server runs only one LIO virtual processor. If the logical-log files are in a dbspace that is mirrored, the database server runs two LIO virtual processors. This class of virtual processors has no parameters associated with it.
The PIO class of virtual processors performs I/O to the physical-log file in the following cases:
Only when kernel asynchronous I/O is implemented and the physical-log file is in raw disk space does the database server uses a KAIO thread in the CPU virtual processor to perform I/O to the physical log. The physical-log file stores before-images of dbspace pages that have changed since the last checkpoint. (For more information on checkpoints, refer to Checkpoints.) At the start of recovery, prior to processing transactions from the logical log, the database server uses the physical-log file to restore before-images to dbspace pages that have changed since the last checkpoint. I/O to the physical-log file is the second-highest priority I/O after I/O to the logical-log files.
If the physical-log file is in a dbspace that is not mirrored, the database server runs only one PIO virtual processor. If the physical-log file is in a dbspace that is mirrored, the database server runs two PIO virtual processors. This class of virtual processors has no parameters associated with it.
The database server performs database I/O asynchronously, meaning that I/O is queued and performed independently of the thread that requests the I/O. Performing I/O asynchronously allows the thread that makes the request to continue working while the I/O is being performed.
The database server performs all database I/O asynchronously using one of the following facilities:
Database I/O includes I/O for SQL statements, read-ahead, page cleaning, and checkpoints, as well as other I/O.
The database server uses kernel-asynchronous I/O when the following conditions exist:
The database server implements kernel-asynchronous I/O by running a KAIO thread on the CPU virtual processor. The KAIO thread performs I/O by making system calls to the operating system, which performs the I/O independently of the virtual processor. The KAIO thread can produce better performance for disk I/O than the AIO virtual processor can because it does not require a switch between the CPU and AIO virtual processors.
Informix implements kernel-asynchronous I/O when it ports the database server to a platform that supports this feature. The database server administrator does not configure kernel-asynchronous I/O. To see if kernel-asynchronous I/O is supported on your platform, see the machine notes file.
If the platform does not support kernel-asynchronous I/O or if the I/O is to buffered-file chunks, the database server performs database I/O through the AIO class of virtual processors. All AIO virtual processors service all I/O requests equally within their class.
The database server assigns each disk chunk a queue, sometimes known as a gfd queue, based on the filename of the chunk. The database server orders I/O requests within a queue according to an algorithm that minimizes disk-head movement. The AIO virtual processors service queues that have work pending in round-robin fashion.
All other non-chunk I/O is queued in the aio queue.
Use the NUMAIOVPS parameter to specify the number of AIO virtual processors that the database server starts initially. For information about NUMAIOVPS, refer to chapter on configuration parameters the IBM Informix: Administrator's Reference.
You can start additional AIO virtual processors while the database server is in online mode. For more information, refer to Adding Virtual Processors in Online Mode.
You cannot drop AIO virtual processors while the database server is in online mode.
The goal in allocating AIO virtual processors is to allocate enough of them so that the lengths of the I/O request queues are kept short; that is, the queues have as few I/O requests in them as possible. When the gfd queues are consistently short, it indicates that I/O to the disk devices is being processed as fast as the requests occur. The onstat -g ioq command allows you to monitor the length of the gfd queues for the AIO virtual processors. For more information, refer to Monitoring Virtual Processors.
If the database server implements kernel-asynchronous I/O on your platform, and all of your dbspaces are composed of raw disk space, one AIO virtual processor might be sufficient.
If the database server implements kernel-asynchronous I/O, but you are using some buffered files for chunks, allocate two AIO virtual processors per active dbspace that is composed of buffered file chunks. If kernel-asynchronous I/O is not implemented on your platform, allocate two AIO virtual processors for each disk that the database server accesses frequently.
Allocate enough AIO virtual processors to accommodate the peak number of I/O requests. Generally, it is not detrimental to allocate too many AIO virtual processors.
Home | [ Top of Page | Previous Page | Next Page | Contents | Index ]