PROCESS_CREATION_DELAY.

1. For your specific installation configuration and machine, measure the amount of operating system processing resources consumed by a Teamcenter server to be started and added to the warm pool. This can be done simply by looking at the processing resources consumed by a server in a newly started up (but unused) pool. This can be expressed as [warmCPUSec] in units of CPU seconds.

2. Determine what fraction of the machine can be dedicated to starting up new server in response to logon demand during the peak usage of the system. Note that processing resources used to start new servers is resource that is not available to support established active session transactions. Siemens PLM Software recommends values for this between 0.4 and 0.7. This can be expressed as [warmFraction] (unitless). A lower value for this fraction reserves more of the machine processing resources for concurrent nonstartup activity.

3. Determine how many CPUs are on the machine ([numCPUs]).

4. Calculate optimum process creation delay in units of milliseconds (mSec) as follows:

[optimumDelay] = ( [warmCPUSec] * [1000 mSec/Sec]) /( [warmFraction] * [numCPUs])

5. Set PROCESS_CREATION_DELAY to an increasing value list of delays, starting with the optimum (or slightly under), and generally ramping up to

about 60000 milliseconds. The pool manager moves across the list based on number of consecutive start failures.

Example: [warmCPUSec] = 8 seconds [warmFraction] = 0.6 [num_CPUs] = 2 [optimumDelay] = (8 * 1000) / (0.6 * 2) = 6667 PROCESS_CREATION_DELAY = 6667 7000 12000 24000 40000 60000

By default, PROCESS_CREATION_DELAY is not explicitly placed in the file. The default value for PROCESS_CREATION_DELAY is the list 2000 2000 8000

16000 30000 60000 (values in milliseconds), so that if the default were used on the

machine, a demand for > 100% CPU would occur whenever the pool manager tried to ramp up more than one server. To override the default, the entire line must be added to the file.

Note _{PROCESS_CREATION_DELAY is the most important parameter to set to}

prevent CPU overload on pool servers due to starting multiple new servers.

Setting the PROCESS_MAX parameter

The only concern for limiting the maximum number of Teamcenter servers on a machine might be memory consumption. The incremental free memory per server can be expected to vary a bit from installation to installation, but is on the order of 30 megabytes.

Determine the maximum amount of RAM on the machine that you want do provide to the Teamcenter servers in the pool. This can be expressed as [maxTCmem] in gigabytes.

Set PROCESS_MAX = [maxTCmem] * [1024 MB/GB] / [30 MB] For example:

[maxTCmem] = 4 Gig

PROCESS_MAX = 4 * 1024 / 30 = 136

Setting the PROCESS_TARGET parameter

PROCESS_TARGET is a series of comma-delimited local time and pool minimum

pairs.

For example:

0700 20, 0730 50, 1100 20, 1300 50, 1900 10

This specifies that at 0700 local time, the pool manager should ensure that a minimum of 20 Teamcenter servers are in the pool, and at 0730 at least 50, and so on, until 1900 when the pool minimum drops to 10.

An example is 0000 5. This specifies that the pool manager maintain a minimum of 5 at all times.

It is desirable that this time profile be a reasonably good estimate of the number of servers needed by user demand. This can be estimated by occasionally monitoring the number of servers assigned to users throughout a representative workday. If this profile is well configured, the value of tuning the next parameter,

PROCESS_WARM, becomes low.

When choosing the time to set a new minimum, realize that it takes time (based upon

level. For example, if it is determined that there should be a minimum of 200 at time 1300, and the previous minimum was 100, and PROCESS_CREATION_DELAY has been tuned to 5000 milliseconds, then it could take about (200 – 100) * 5000 = 500,000 milliseconds = 500 seconds = 8.3 minutes to ramp up the additional 100 processes. Thus the limit should be configured to 200 at around time 1250 to ensure 200 are all warm or in use at time 1300.

Setting the PROCESS_WARM parameter

This setting is the most difficult to optimize, because it requires an estimate of the burst rate of logons that may occur. The following discussion examines some of the theory behind what drives a good value. After the theory, more practical statements about tuning this value are presented.

If the PROCESS_WARM value is set too low, users in the rear of a burst of logon requests may encounter thetcserver is not available, try again latermessage,

and a later logon will be successful.

To minimize this situation, the PROCESS_WARM value can be increased. As defined at the start, PROCESS_WARM is a desired number of Teamcenter servers to be warm, but not assigned.

This configuration value comes into play if the sum of assigned servers +

PROCESS_WARM is greater than the PROCESS_TARGET for that time of day.

In this case, the pool manager responds to a logon (which moves a server state from warm to assigned) by starting one or more servers (not to exceed the rate dictated by

PROCESS_CREATION_DELAY) to make up the PROCESS_WARM deficit.

A burst of logon requests begins in a state with the warm pool fully populated, extends until the warm pool is again fully populated, and contains one or more logon intervals faster than the rate dictated by the PROCESS_CREATION_DELAY. A new Teamcenter server takes a minimum of [warmCPUSec] seconds to become available, and then they are added to the pool at a maximum rate of one every

PROCESS_CREATION_DELAY.

The following graphic illustrates an assignment burst that starts at time T1, and continues until it exhausts the number of available warm servers sometime later during the time new servers are being added to the pool.

The number of Teamcenter servers added as warm per second after the delay [warmCPUSec] is (1000 mSec/Sec) / PROCESS_CREATION_DELAY.

• If the burst interval is less than [warmCPUSec], a burst of logons greater than

PROCESS_WARM encounters an empty warm pool.

• If the burst interval is greater than [warmCPUSec], a burst of logons greater than PROCESS_WARM + (1000 * ([burst_interval] – [warmCPUSec])) /

PROCESS_CREATION_DELAY encounters an empty warm pool.

Typically, you do not need to perform this level of detailed analysis on pool logon demands. Note that:

• Large PROCESS_CREATION_DELAY values should prompt you to configure larger PROCESS_WARM pools.

Note _{Large PROCESS_CREATION_DELAY values should be configured for}

low numbers of server CPUs or long values of [warmCPUSec]. If you chose a low fraction of the machine to be used to start up new servers to compute optimum PROCESS_CREATION_DELAY, you may want to configure a larger PROCESS_WARM value to compensate for the longer startup delays.

• Excessive occurrences of low or exhausted warm margins should prompt either an upward adjustment of the PROCESS_WARM value, the PROCESS_TARGET minimum for that time of day, or both.