Operands related to processes

1) pd_max_bes_process = maximum-number-of-activated-processes-per-back-end-server

<unsigned integer>((1-2048))<<pd_max_users value>>

Specifies the maximum number of processes that can be activated per back-end server. For multi front-end servers, processes that exceed the value specified in the pd_max_users can sometimes become concentrated in a single back-end server. The pd_max_bes_process operand specifies the maximum number of processes that can be activated per back-end server when that number exceeds the value of the pd_max_users operand.

Condition: This operand is applicable when multiple front-end servers are used.

Specification guidelines

The value determined by the following formula indicates the maximum number of processes that may become concentrated in a single back-end server.
pd_max_users value number-of-front-end-servers
Specify a value for the pd_max_bes_process operand by using the value determined here as the upper limit and taking the degree of process concentration in a single back-end server into consideration. Specifying an unnecessarily large value may cause memory shortage.
If the value specified is smaller than the pd_max_users value, the pd_max_users value is assumed as the default, and a warning message (KFPS01888-W) is output.
If updatable online reorganization is used, specify an operand value that satisfies the following condition. Otherwise, HiRDB cannot be started.
pd_max_bes_process + pd_max_reflect_process_count value 2048

Tuning the specified value: For details about how to tune the maximum number of processes that can be activated, see the HiRDB Version 8 System Operation Guide.

2) pd_max_dic_process = maximum-number-of-activated-processes-per-dictionary-server

<unsigned integer>((1-2048))<<pd_max_users value>>

Specifies the maximum number of processes that can be activated per dictionary server. When multiple front-end servers are used, processes that exceed the value specified in pd_max_users can sometimes become concentrated in a single dictionary server. Even when multiple front-end servers are not used, processes that exceed the value specified in pd_max_users can become concentrated in a single dictionary server if the number of executions of operation commands related to RDAREAs and global buffers (pdbufls, pddbls, pdopen, pdclose, pdhold, and pdrels) exceeds the value specified in pd_max_users.

The pd_max_dic_process operand specifies the maximum number of processes that can be activated per dictionary server when that number exceeds the value of the pd_max_users operand.

Specification guidelines

The value determined by the following formula indicates the maximum number of processes that may become concentrated in a single dictionary server:
pd_max_users value number-of-front-end-servers
Specify a value for the pd_max_dic_process operand by using the value determined here as the upper limit and taking the degree of process concentration in a single dictionary server into consideration. Specifying an unnecessarily large value may cause memory shortage.
If the execution of operation commands related to RDAREAs or global buffers causes processes to become concentrated in a single dictionary server, the number of operation commands to be concurrently executed becomes the maximum number for this operand.
If the value specified is smaller than the pd_max_users value, the pd_max_users value is assumed as the default, and a warning message (KFPS01888-W) is output.
If updatable online reorganization is used, specify an operand value that satisfies the following condition. Otherwise, HiRDB cannot be started.
pd_max_dic_process + pd_max_reflect_process_count value 2048

Tuning the specified value: For details about how to tune the maximum number of processes that can be activated, see the HiRDB Version 8 System Operation Guide.

3) pd_process_count = resident-processes-count[,resident-processes-count-at-server-startup]

<unsigned integer>((0-2048))

resident-processes-count: Specifies the number of processes that can be made resident in each server. A resident process is a process that is activated at the time the server is started.

Advantage: By activating the processes used by transactions that can be processed concurrently by each server at the time of system startup and keeping them resident, the process startup time can be reduced even when new transactions are entered. However, HiRDB startup will take longer.

Specification guidelines

The value to be specified is determined on the basis of the process private area of each server process and the real memory size of the processor. For details about the process private areas of server processes, see the HiRDB Version 8 Installation and Design Guide.
If a multi front-end server configuration is used and if the pd_max_bes_process or pd_max_dic_process operand is specified in addition, specify for the pd_process_count operand a value that satisfies the following conditions:
pd_process_count value pd_max_bes_process or pd_max_dic_process value

The value specified for this operand should be within the maximum number of processes that can be activated for each server, as shown in the following table:

Server type		Maximum number of processes that can be activated
Single server		pd_max_users + pd_max_reflect_process_count value
Front-end server	Multiple front-end servers	pd_max_users + pd_max_reflect_process_count value + 1
Front-end server	Not multiple front-end servers	pd_max_users + pd_max_reflect_process_count value
Dictionary server		pd_max_dic_process^* + pd_max_reflect_process_count value
Back-end server		pd_max_bes_process^* + pd_max_reflect_process_count value

^* If the pd_max_dic_process or pd_max_bes_process operand is omitted, the value of the pd_max_users operand is assumed as the default.

Tuning the specified value: For details about how to tune the resident processes count, see the HiRDB Version 8 System Operation Guide.

Notes

Because the resident processes count has an effect on memory space availability, specifying an unnecessarily large number may prevent HiRDB from starting.
If more processes than the resident process count are needed, additional processes are dynamically started, up to the maximum processes count allowed. However, depending on the value specified for the pd_max_server_process operand, it may not be possible to start all of the processes indicated by the maximum processes count.

Operand rules

If this operand is omitted (or 0 is specified for it) and the operands are omitted (or 0 is specified for them) in server definitions as well, the following values are assumed:

For a single server or back-end server: maximum number of processes that can be activated
For a front-end server or dictionary server: maximum-number-of-processes-that-can-be-activated 2

resident-processes-count-at-server-startup

Specifies the number of processes that can be made resident during HiRDB startup.

It is common for resident processes to be activated during HiRDB startup. If there are many resident processes, the amount of time required for HiRDB startup increases proportionately. For example, it takes approximately 1 second to activate a process on a server machine with a 100-MIPS performance rating.

Following are the differences in processing that result depending on whether or not a resident processes count at server startup is specified:

When there is no specification of a resident processes count at server startup (when, for example, pd_process_count = 500 is specified)
All 500 resident processes are activated during HiRDB startup, and HiRDB will not start until they are all activated. In this example, it would take a 100-MIPS server machine about 500 seconds to activate all the resident processes during HiRDB startup.
When a resident processes count at server startup is specified (when, for example, pd_process_count = 500,50 is specified)
Some of the resident processes (50 in this case) are activated during HiRDB startup, and the remaining resident processes are activated after HiRDB startup. HiRDB can be started as long as the specified number of resident processes are activated. In this example, it would take a 100-MIPS server machine about 50 seconds to activate 50 resident processes during HiRDB startup. The remaining 450 resident processes (in this example) would be activated after HiRDB startup.

Advantage: The amount of time required for HiRDB startup is reduced. This option should be used when it is desirable to reduce the HiRDB startup time as much as possible, such as when the system switchover facility is being used.

Specification guidelines: The specified value should be equal to the number of processes that will be required immediately after HiRDB startup is completed.

Note: When a resident processes count at server startup is specified, the value in the PDCWAITTIME operand of the client environment definition should be rechecked.; If more UAPs than the resident processes count at server startup are to be executed immediately following HiRDB startup, transaction processing may not be performed until after the remaining resident processes have been activated. Therefore, if the value specified in the PDCWAITTIME operand of the client environment definition is small, it may not be possible to process some UAPs due to timeouts. For details about the PDCWAITTIME operand, see the HiRDB Version 8 UAP Development Guide.

4) pd_server_cleanup_interval = interval-for-stopping-nonresident-server-processes

<unsigned integer> ((0-1440))<<0>> (minutes)

Specifies in minutes the interval for checking for nonresident server processes in HiRDB that are to be stopped. The facility for stopping nonresident server processes is applied when the number of executing server processes exceeds the number of processes that can be made resident (value specified by the pd_process_count operand). The number of server processes that the facility stops is computed automatically by HiRDB.

Advantage: This facility improves the utilization rates of the memory and of process resources because it increases the number of nonresident processes that can be reused when the workload (number of server processes that are executing) peaks.

Specification guidelines

For example, if there is only one hour a day during which peak workload occurs and the intervals between peaks within that hour are approximately two minutes apart, 2 should be specified for this operand.
This facility does not have any effect if the number of server processes that execute concurrently during peak periods is always fewer than the number of resident processes. In this case, this operand should be omitted.

Tuning the specified value: Collect statistical information on system operations for each server for one week. Determine the workload peaks from the number of server processes being serviced (# OF PROCESSES ON SERVICE). If that peak value exceeds the currently set number of processes that can be made resident (value specified by the pd_process_count operand), determine the interval between individual peaks and set that number of minutes.; However, if there are ample resources, such as memory and CPU, in the server machine, adding the shortfall in the number of processes to the number of resident processes (i.e., increasing the value of the pd_process_count operand) would be more effective in improving performance than specifying the pd_server_cleanup_interval operand.

Note: When this operand is omitted or 0 is specified, the system checks every 10 seconds for nonresident server processes that are waiting to be serviced and stops any such processes that are found.

5) pd_svr_castoff_size = maximum-memory-size-used-by-server-process

<unsigned integer>((0-2048))<<0>> (MB)

This operand need not be specified for the Linux version.

Specifies the maximum amount of memory space that can be used by a server process. If at the applicable trigger point shown below the amount of memory being used by a server process exceeds the value specified here, that server process is terminated. When a server process is so terminated, the KFPS00350-w message is output. This is called the facility for monitoring the memory size of server processes; for details, see the HiRDB Version 8 System Operation Guide.

Server type	Process name	Process termination trigger
Single server	pdsds	At UAP disconnection
Front-end server	pdfes	At UAP disconnection
Dictionary server	pddic	At transaction decision
Back-end server	pdbes	At transaction decision

Advantages

The facility for monitoring the memory size of server processes resolves the following problem:

The memory size of a server-resident process becomes too large during a particular SQL processing, significantly reducing the amount of system memory that is available.

The HiRDB server releases memory space that is no longer needed. However, even when a program releases memory, the OS holds the memory area itself in the memory management facility inside the applicable process. Consequently, a process that becomes large in terms of using a large memory area even once never shrinks and continues to have an adverse impact on the system, especially in the case of resident processes. The facility for monitoring the memory size of server processes can prevent memory shortages because it terminates even resident processes.

Application criterion: Apply this facility when the amount of memory space used by a HiRDB server process becomes large, resulting in memory shortages.

Specification guidelines

Maximum value for this operand
Normally, specify a value by considering the maximum processing capability of HiRDB. Assuming that the maximum number of SQLs may be concurrently connected, determine for this operand a value that satisfies the following condition in each unit:
a (b + c) < d
a: Number of server processes within the unit (maximum-number-of-concurrent-connections server-count-inside-unit)
b: Virtual memory size for one server process immediately following HiRDB startup
c: pd_svr_castoff_size operand value
d: Memory size that can be allocated to a unit (memory size excluding the area used by other programs)
Minimum value for this operand
If the value specified for this operand is smaller than the memory size needed for normal SQL processing, the efficiency of making processes resident will deteriorate, resulting in frequent process terminations and restarts. Each time this occurs, a message is output to the syslogfile or the message log file, resulting in further performance degradation. To prevent this, select for this operand a value that satisfies the following condition for each server:
a - b < c
a: Server process virtual memory size following SQL process termination
b: Virtual memory size for server process immediately following HiRDB startup
c: pd_svr_castoff_size operand value

The virtual memory size can be determined by an OS command (e.g., the top command in HP-UX).

Operand rule: When 0 is specified for this operand, the facility for monitoring the memory size of server processes is not applied.

6) pd_max_ard_process = asynchronous-READ-process-count

<unsigned integer>((0-256))<<0>>

Specify this operand if you use the asynchronous READ facility. For this operand, specify the number of processes necessary for asynchronous READ operations. For a HiRDB/Parallel Server, this operand specifies the number of processes per server (back-end server or dictionary server). For details on the asynchronous READ facility, see the HiRDB Version 8 Installation and Design Guide.

Condition: A value of 1 or greater must be specified for the -m option of the pdbuffer operand.

Advantage

The asynchronous READ facility is especially effective (improves performance) when character special files, for which input and output take a long time, are used. Conversely, when regular files, for which input and output do not take a long time, or SANRISE disks are used, the asynchronous READ facility may not have much effect because:

Input/out time does not overlap with CPU time most of the time.
Communication processing has a large overhead.

Specification guidelines

Specify 0 or 1. However, if a value between 2 and 256 is specified for the -m option of the pdbuffer operand, specify the same value as the -m option value. If a value greater than 256 is specified for the -m option, specify the same value as the number of disk devices that store RDAREAs and system files (the number of such disk devices per server for a HiRDB/Parallel Server) or 256.
Increasing the value of this operand can shorten the processing time when the degree of concurrency is high for the SQL statements to which the asynchronous READ facility is applied. Decreasing the value of this operand may lengthen the processing time when the degree of concurrency is high for the SQL statements to which the asynchronous READ facility is applied. This is because asynchronous READ processes may have to wait for processing completion.
Because a number of processes equaling value-of-this-operand server-count are started, determine a value for this operand by taking resources (shared memory and message queue) into consideration. For the method of estimating shared memory and message queue sizes, see the HiRDB Version 8 Installation and Design Guide.

Tuning the specified value: For the method of tuning the specification value (the number of asynchronous READ processes), see the HiRDB Version 8 System Operation Guide.

Relationship to other operands: If you change the value of this operand, reevaluate the value of the pd_max_server_process operand.

Operand rule: If you specify 0 for this operand, the asynchronous READ facility is not used.

7) pd_dfw_awt_process = number-of-processes-to-be-written-in-parallel-in-deferred-write

<unsigned integer>((2-255))

Specify this operand when you use the facility for parallel writes in deferred write processing for all buffer pools. Specify for this operand the number of processes to be processed in parallel. Increasing the number of processes can shorten the write processing time. For details about the facility for parallel writes in deferred write processing, see the HiRDB Version 8 Installation and Design Guide.

Specification guidelines: Specify 2, which is the smallest value that enables the facility for parallel writes in deferred write processing. Furthermore, to determine the value for this operand, see Tuning deferred write processing in the HiRDB Version 8 Installation and Design Guide.

Note: Specifying the facility for parallel writes in deferred write processing increases the number of processes and consequently raises the CPU usage rate.

4.3.1 Operands related to processes