6.2.1 Operands related to processes

1) pd_process_count = resident-processes-count[,resident-processes-count-at-server-startup]
~<unsigned integer>((0-2000))
resident-processes-count
Specifies the number of processes that can be made resident in the front-end 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 the front-end 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
  • Determine the value to be specified based on the process private area allocated to the front-end server's server process and the amount of real memory in the processor. For details about the process private area of the server process, see the HiRDB Version 9 Installation and Design Guide.
  • In a multiple front-end server configuration, if the pd_max_bes_process or pd_max_dic_process operand has also been specified, the value specified for this operand must satisfy the following condition:
    Value of pd_process_count[Figure] value of pd_max_bes_process or pd_max_dic_process
  • For this operand, specify a value that is no more than the front-end server's maximum number of processes that can be activated.
    Server typeMaximum number of processes that can be activated
    Multiple front-end serversValue of pd_max_users + value of pd_max_reflect_process_count + 1
    Other than multiple front-end serversValue of pd_max_users + value of pd_max_reflect_process_count
Tuning the specified value
For details about how to tune the resident processes count, see the HiRDB Version 9 System Operation Guide.
Notes
  • Because the number of resident processes has a direct effect on the availability of memory space and on the CPU, specifying an unnecessarily large number might prevent HiRDB from starting or might degrade the server machine's processing performance.
  • 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 might not be possible to start all of the processes indicated by the maximum processes count.
Operand default value
If this operand is omitted (or 0 is specified), the value specified for the same operand in the server common definition takes effect. If the same operand is also omitted from the server common definition, the following value is assumed:
[Figure]maximum number of processes that can be activated[Figure] 2[Figure]
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.
The differences in processing that result depending on whether a resident processes count at server startup is specified are as follows:
  • 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. Use this option when you want to reduce the HiRDB startup time as much as possible, such as when you are using the system switchover facility.
Specification guideline
Specify a value equal to the number of processes that will be required immediately after HiRDB startup is completed.
Notes
When you specify a resident processes count at server startup, recheck the value in the PDCWAITTIME operand of the client environment definition.
If more UAPs than the resident processes count at server startup are to be executed immediately following HiRDB startup, transaction processing might 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 might not be possible to process some UAPs due to timeouts. For details about the PDCWAITTIME operand, see the HiRDB Version 9 UAP Development Guide.
2) pd_server_cleanup_interval = interval-for-stopping-nonresident-server-processes
~<unsigned integer>((0-1440)) (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.
Advantages
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, specify 2 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, omit this operand.
Operand default value
If this operand is omitted, the value specified for the same operand in the server common definition takes effect. If the same operand is also omitted from the server common definition, 0 is assumed.
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 (in other words, increasing the value of the pd_process_count operand) is more effective in improving performance than specifying the pd_server_cleanup_interval operand.
Note
If 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.
3) pd_svr_castoff_size = maximum-memory-size-used-by-server-process
~<unsigned integer>((0-2048)) (megabytes)
This operand need not be specified for the Linux edition.
Specifies the maximum size of memory used by each server process processed by the front-end server. 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 9 System Operation Guide.
Server typeProcess nameProcess termination trigger
Front-end serverpdfesAt UAP disconnection
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 the maximum number of SQL statements that can execute concurrently, which is dependent on the maximum number of concurrent connections, determine for this operand a value that satisfies the following condition in each unit:
    a[Figure] (b + c) < d
    a: Number of server processes in the unit (maximum number of concurrent connections[Figure] number of servers in the 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 (for example, the top command in HP-UX).
Operand default value
If this operand is omitted, the value specified for the same operand in the server common definition takes effect. If the same operand is also omitted from the server common definition, 0 is assumed.
Operand rules
When 0 is specified for this operand, the facility for monitoring the memory size of server processes is not applied.