Making additional performance improvements
Before Informix 11.70, fragmentation was done by round robin and expression. In Informix 11.70, two new fragmentation schemes are available: interval and list. The interval strategy provides a mechanism for allowing fragments on values that are not yet known. The list strategy lets the user fragment on discreet values.
This section describes new parallelism approaches during backup and restore.
Before V11, whole system backups were single threaded. One single
archive checkpoint timestamp was taken for all dbspaces, and the
archived serially. A parallel whole system backup can be done in V11
by appropriately configuring
BAR_MAX_BACKUP, as shown in Table 9.
Table 9. Setting BAR_MAX_BACKUP
|Unset||Four parallel processes created|
|0||Allows the engine to decide. The engine allocates the lesser of the number of storage spaces or how many can be accommodated in shared memory.|
|1||Serial (single-threaded) archive and restore|
|#||Start number of backup processes|
A checkpoint is performed for all dbspaces just before the backup of the rootdbs. The root dbspace is archived first without parallelism. Up until this point, it is the same behavior as previous versions.
Starting in V11, backup of remaining dbspaces is executed in a new order. This order is the same as used for non-whole-system backups. A before-image processor thread (arcbackup2) is started for each dbspace. This enables more threads to run in parallel. As each dbspace backup is completed, the corresponding arcbackup2 thread exits, resulting in fewer arcbackup2 threads taking up resources as backup progresses.
The new dbspace backup order is based on the used-pages count at
start time of backup. Dbspaces to be backed up are ordered by the
number of used pages in the dbspaces in a descending order. This
ensures better parallelism. This takes effect no matter how
BAR_MAX_BACKUP is set or how many pages are
to be archived.
Special classes of virtual processors can be created to run user-defined routines or to perform the work for a DataBlade module. User-defined routines are typically written to support user-defined data types. If you do not want a user-defined routine to run in the CPU class, which is the default, you can assign it to a user-defined class of virtual processors (VPs). Another name for user-defined virtual processors is extension virtual processors.
If your UDR can do its work in parallel, you should configure enough user-defined virtual processors to handle the multiple tasks the UDR does. The database server will support as many user-defined VPs as the operating system will allow.
User-defined classes of virtual processors can protect the database server from ill-behaved user-defined routines. An ill-behaved user-defined routine has at least one of the following characteristics:
- It does not yield control to other threads
- It makes blocking operating system calls
- It modifies the global VP state
Assigning any ill-behaved user-defined routines to a user-defined class of virtual processor protects the database server against unsafe execution, which enhances reliability of the server. User-defined VPs remove the following programming restrictions on the CPU VP class:
- The need to yield the processor regularly. Because only a thread running the UDR is running on the extension virtual processor, there is no need to yield.
- The need to eliminate blocking I/O calls.
UDRs running on user-defined virtual processors are not required to yield the processor. They might issue filesystem calls that block further processing by the processor until I/O is completed. Impact on other running threads is reduced when these UDRs are running on the user-defined virtual processor, rather than the CPU VPs.
VPCLASS option is used to define a new
VP class. The class name corresponds to the CLASS defined in the
The CREATE FUNCTION statement registers a user-defined routine. The function name is defined, along with the return type and the name of the class that the function runs in.
As an example, in Listing 33, the user-defined routine AllLowerCase is defined. It specifies that the parameter type given is a char, and it defines that the return type is a BOOLEAN. Notice that the class name is also specified. This means that calls to this routine are run in the user-defined VP class named ALC.
Listing 33. Sample SQL to create a UDR
CREATE FUNCTION AllLowerCase(char) RETURNS boolean WITH (CLASS = ALC ) EXTERNAL NAME '/usr/lib/objects/udrs.so' LANGUAGE C
ONCONFIG file must include a
VPCLASS parameter that defines the ALC
class. If not, calls to the AllLowerCase function will fail.