It is recommended that you use the VPCLASS parameter as an alternative to the following parameters:
When you use VPCLASS, you must explicitly remove these other parameters from your ONCONFIG file. For more information on which configuration parameters to remove, see your IBM Informix: Administrator's Guide.
The VPCLASS configuration parameter allows you to specify a class of virtual processors, the number of virtual processors that the database server should start for a specific class, and the maximum number allowed.
To execute user-defined routines (UDRs), you can define a new class of virtual processors to isolate UDR execution from other transactions that execute on the CPU virtual processors. Typically you write user-defined routines to support user-defined data types. For more information on the purpose of user-defined virtual processors, see your IBM Informix: Dynamic Server Administrator's Reference and the IBM Informix: User-Defined Routines and Data Types Developer's Guide.
If you do not want a user-defined routine to affect the normal processing of user queries in the CPU class, you can use the CREATE FUNCTION statement to assign the routine to a user-defined class of virtual processors. The class name that you specify in the VPCLASS parameter must match the name specified in the CLASS modifier of the CREATE FUNCTION statement. For more information on the CREATE FUNCTION statement, see the IBM Informix: Guide to SQL Syntax.
The cpu and num options of the VPCLASS parameter specifies the number of CPU VPs that the database server brings up initially. Do not allocate more CPU VPs than there are CPUs available to service them.
Use the following guidelines to set the number of CPU VPs:
VPCLASS cpu,num=1
VPCLASS cpu,num=3
When you use this setting, one processor is available to run the database server utilities or the client application.
For dual-processor systems, you might improve performance by running with two CPU VPs. To test if performance improves, set NUMCPUVPS to 1 in your ONCONFIG file and then add a CPU VP dynamically at runtime with onmode -p.
If you are running multiple CPU VPs, set the MULTIPROCESSOR parameter to 1. When you set MULTIPROCESSOR to 1, the database server performs locking in a manner that is appropriate for a multiprocessor. Otherwise, set this parameter to 0.
The number of CPU VPs is used as a factor in determining the number of scan threads for a query. Queries perform best when the number of scan threads is a multiple (or factor) of the number of CPU VPs. Adding or removing a CPU VP can improve performance for a large query because it produces an equal distribution of scan threads among CPU VPs. For instance, if you have 6 CPU VPs and scan 10 table fragments, you might see a faster response time if you reduce the number of CPU VPs to 5, which divides evenly into 10. You can use onstat -g ath to monitor the number of scan threads per CPU VP or use onstat -g ses to focus on a particular session.
If you are running only one CPU VP, set the SINGLE_CPU_VP configuration parameter to 1. Otherwise, set this parameter to 0.
Cannot have 'SINGLE_CPU_VP' non-zero and 'NUMCPUVPS' greater than 1
When you set the SINGLE_CPU_VP parameter to 1, you cannot add CPU VPs while the database server is in online mode.
The noage option of the VPCLASS parameter allows you to disable process priority aging for database server CPU VPs on operating systems that support this feature. Priority aging is when the operating system lowers the priority of long-running processes as they accumulate processing time. You might want to disable priority aging because it can cause the performance of the database server processes to decline over time.
Your database server distribution includes a machine notes file that contains information on whether your version of the database server supports this feature. For information on where to find this machine notes file, see the Introduction to this guide.
Specify the noage option of VPCLASS if your operating system supports this feature.
The aff option of the VPCLASS parameter specifies the processors to which you want to bind CPU VPs or AIO VPs. When you assign a CPU VP to a specific CPU, the VP runs only on that CPU; other processes can also run on that CPU.
The database server supports automatic binding of CPU VPs to processors on multiprocessor host computers that support processor affinity. Your database server distribution includes a machine notes file that contains information on whether your version of the database server supports this feature. For information on where to find the machine notes file, see the Introduction to this guide.
You can use processor affinity for the purposes that the following sections describe.
You can use processor affinity to distribute the computation impact of CPU VPs and other processes. On computers that are dedicated to the database server, assigning CPU VPs to all but one of the CPUs achieves maximum CPU utilization. On computers that support both database server and client applications, you can bind applications to certain CPUs through the operating system. By doing so, you effectively reserve the remaining CPUs for use by database server CPU VPs, which you bind to the remaining CPUs with the VPCLASS configuration parameter. Set the aff option of the VPCLASS parameter to the numbers of the CPUs on which to bind CPU VPs. For example, the following VPCLASS setting assigns CPU VPs to processors 4 to 7:
VPCLASS cpu,num=4,aff=4-7
If you specify a larger number of CPU VPs than physical CPUs, the database server starts assigning CPU VPs from the starting CPU again. For example, suppose you specify the following VPCLASS settings:
VPCLASS cpu,num=8,aff=4-7
The database server makes the following assignments:
On a system that runs database server and client (or other) applications, you can bind asynchronous I/O (AIO) VPs to the same CPUs to which you bind other application processes through the operating system. In this way, you isolate client applications and database I/O operations from the CPU VPs. This isolation can be especially helpful when client processes are used for data entry or other operations that require waiting for user input. Because AIO VP activity usually comes in quick bursts followed by idle periods waiting for the disk, you can often interweave client and I/O operations without their unduly impacting each other.
Binding a CPU VP to a processor does not prevent other processes from running on that processor. Application (or other) processes that you do not bind to a CPU are free to run on any available processor. On a computer that is dedicated to the database server, you can leave AIO VPs free to run on any processor, which reduces delays on database operations that are waiting for I/O. Increasing the priority of AIO VPs can further improve performance by ensuring that data is processed quickly once it arrives from disk.
The database server assigns CPU VPs to CPUs serially, starting with the CPU number you specify in this parameter. You might want to avoid assigning CPU VPs to a certain CPU that has a specialized hardware or operating-system function (such as interrupt handling).
To avoid a certain CPU, set the aff option of the VPCLASS parameter to a range of values that excludes that CPU number. For example, the following specification avoids CPU number 2 and assigns CPU VPs to CPU numbers 3, 0, and 1:
VPCLASS cpu,num=3,aff=3-1
The aio and num options of the VPCLASS parameter indicate the number of AIO VPs that the database server brings up initially. If your operating system does not support kernel asynchronous I/O (KAIO), the database server uses AIO VPs to manage all database I/O requests.
The recommended number of AIO VPs depends on how many disks your configuration supports. If KAIO is not implemented on your platform, it is recommended that you allocate one AIO VP for each disk that contains database tables. You can add an additional AIO VP for each chunk that the database server accesses frequently.
The machine notes file for your version of the database server indicates whether the operating system supports KAIO. If KAIO is supported, the machine notes describe how to enable KAIO on your specific operating system. For information on where to find the machine notes file, see the Introduction to this guide.
If your operating system supports KAIO, the CPU VPs make I/O requests directly to the file instead of the operating-system buffers. In this case, configure only one AIO VP, plus two additional AIO VPs for every buffered file chunk.
The goal in allocating AIO VPs 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 I/O request queues remain consistently short, I/O requests are processed as fast as they occur. The onstat -g ioq command allows you to monitor the length of the I/O queues for the AIO VPs.
Allocate enough AIO VPs to accommodate the peak number of I/O requests. Generally, allocating a few extra AIO VPs is not detrimental. To start additional AIO VPs while the database server is in online mode, use the onmode -p command. You cannot drop AIO VPs in online mode.
Enterprise Edition Home | Express Edition Home | [ Top of Page | Previous Page | Next Page | Contents | Index ]