Key Server Configuration Parameters
Explicitly Allocating a Process to a CPU
Link Management for NonStop TS/MP Application Servers
This topic discusses considerations for achieving enhanced load balancing among NonStop DOM application server processes configured through NonStop TS/MP and accessed via TCP/IP.
Access to the NonStop DOM server processes configured with NonStop TS/MP is controlled by the PATHMON process and a link monitor process, LINKMON. There is one LINKMON process monitoring each CPU. Access is based on a set of parameters established for each server pool at configuration time. The values you choose for certain parameters determine how well the client request load is balanced across system processes.
The following key server parameters influence application load balancing. For complete details on server parameter definitions and instructions for configuring server pools, refer to the NonStop TS/MP System Management Manual.
Note: In the NonStop TS/MP documentation, a server pool is referred to as a "server class."
The MAXSERVERS server parameter specifies the maximum number of copies of a server process that can run in a given server pool at the same time. Server processes may be static or dynamic. Static processes are started automatically when the NonStop TS/MP environment starts, while dynamic processes are started as needed by the PATHMON process. The number of static processes in a server pool is determined by another configuration variable, the NUMSTATIC parameter. The maximum number of potential dynamic server processes is equal to MAXSERVERS minus NUMSTATIC. To determine the maximum number of links available in a server pool, use the formula MAXSERVERS * MAXLINKS.
This parameter specifies the maximum number of links that any given LINKMON process can have to an individual server process in a server pool.
A link is a connection between the LINKMON process and a specific server process. The link is used to send a request to, and receive a reply from, a server process.
The LINKMON process is the link manager that handles client requests made using the Pathsend protocol. One LINKMON process runs in each CPU on a Tandem system. When it has a link to a server process, the LINKMON process uses the link to pass requests to and from the server process on behalf of all the clients in the LINKMON's CPU.
A LINKDEPTH value of 1 constrains a LINKMON process to establishing just one link per server process in a server pool. A LINKDEPTH value of 10, on the other hand, allows each LINKMON process to have a maximum of 10 concurrent links to each server process.
The MAXLINKS parameter specifies the maximum number of links that a server process in a pool can have to all LINKMON processes in the system. Consequently, while a server process is processing a request, a number of requests up to the value of MAXLINKS minus 1 can queue at the server.
If the LINKDEPTH setting is 10 and there are 3 CPUs in the system, then MAXLINKS must be set to 30 to avoid queuing at the server process.
Note: It is strongly recommended that you set a value for MAXLINKS; the default is an unlimited number of links.
Figures 1, 2, and 3 depict the potential results of various parameter configurations. Note that the links depicted are only potential scenarios for how the system can behave based on the specified parameter values. For example, Figure 1 shows each of three LINKMON processes establishing a link to a server process in a pool. Yet it is possible that one busy LINKMON process could request and get a link to all three of the server processes, thereby shutting the other LINKMON processes out.
Figure 1. Results of MAXLINKS = 1, LINKDEPTH = NA
Figure 2. Results of MAXLINKS=2, LINKDEPTH=1
Figure 3. Results of MAXLINKS=2, LINKDEPTH=2
Instead of letting the PATHMON process allocate the CPU resources for a given process, you can specify an explicit CPU for processes that have critical performance issues. Normally, you do not need to manually allocate CPUs; the PATHMON process does an excellent job of allocating resources. However, you can take advantage of this allocation method if there is a need to specify an explicit CPU for a critical process.
In general, the PATHMON process allocates CPUs for the NonStop DOM application processes. This behavior is set with the following PATHCOM code:
set server cpus (<n>,...)
This statement allocates the CPUs specified by the argument (<n>, ...) to the NonStop DOM application processes. The PATHMON process allocates these CPUs to the requests that are made by the NonStop DOM system.
To explicitly set a CPU for a specific process, modify the nsdstart script to set up a specific CPU-process relationship. For example, to set a specific CPU for the Comm Server $ZC02, you could enter the following code in the section that configures the Comm Servers:
set server process $ZC02 (cpus <p>:<b>)
This dedicates the CPUs specified by the (cpus <p>:<b>) value to handle the process of the $ZC02 Comm Server. The value <p> stands for the primary CPU, while <b> stands for the backup CPU.
Configuring NonStop TS/MP server processes can be a complex exercise. Many factors come into play when a system is running, so the behavior of a real-life server process in a production configuration can vary. That is why the scenarios shown earlier in Figures 1, 2, and 3 represent only a potential result of specifying a particular set of server parameter values.
How and when a client request actually reaches a server process is the result of collaboration between the LINKMON process and the PATHMON process (the NonStop TS/MP monitor process) in allocating links to the server processes. Proper management of the allocation of links is critical to successful system configuration.
What follows is a brief overview of link dynamics.For a thorough discussion of NonStop TS/MP link management, see the NonStop TS/MP System Management Manual.
The PATHMON process maintains a global list of links available for all application server processes in all server pools in the PATHMON environment. The first time a LINKMON process needs access to a server process in a server pool, the LINKMON process sends a request to the PATHMON process, asking for a link to any process in the server pool.
The PATHMON process consults its internal server pool link tables. If all links are in use, the PATHMON process returns an error to the LINKMON process. This situation might arise due to an unbalanced distribution of client activity across the CPUs of a system. An underutilized LINKMON process may not be able to get a link if other, busier LINKMON processes continue to request and use available links.
If a link is available, PATHMON passes the server process name to the LINKMON process. The PATHMON process also passes the values for CREATEDELAY and DELETEDELAY, timer parameters. The PATHMON process then updates its link tables to reflect the passed link.
If the count of active server processes is less than the values of MAXSERVERS for that server pool, the PATHMON process may start another copy of the server process.
Once a LINKMON process has been granted a link, it can use that link to service requests on behalf of all clients in the LINKMON process's CPU.
A link can be in use for only one client at any one time. A LINKMON process passes a request from a client to the linked server process. The LINKMON passes another request from a client to that server process only when the LINKMON process receives a reply to the first request. Additional client requests, even from the same client, are queued until the link is free.
If requests are queuing, the LINKMON process sets a timer to the value of the CREATEDELAY parameter for the server pool. If the LINKMON process receives a reply from the server process before the timer expires, the LINKMON process immediately uses the existing link to send the next request to the server process. The timer is canceled. If the timer expires before the server process replies, the LINKMON process asks the PATHMON process for another link to a server process in that server pool. The PATHMON process checks its link tables, using MAXLINKS to determine whether all links to that server pool are in use. If not, it uses an algorithm to determine to which server process the LINKMON process will link.
This algorithm examines the current distribution of links across all the server processes in the server pool. The algorithm also examines the LINKDEPTH setting to determine whether to allow the LINKMON process another link to the same server process to which it is already linked.
If LINKDEPTH is set to 1 and the only available link is to the server process to which LINKMON is already linked, the new link connection is denied. The LINKMON process receives an error message.
When a LINKMON process has no current outstanding requests from a server process, it sets a timer to the value of DELETEDELAY for that server pool. If the timer expires before another request arrives from the client, the LINKMON process returns the link to the PATHMON process, which updates its link tables. When all link managers with a link to the server process have returned their links, the PATHMON process waits for the server process to stop itself. The PATHMON process then marks that server process as stopped in its link tables and waits for further requests for links.
When configuring your NonStop TS/MP application server processes, review carefully the descriptions for each server parameter in the NonStop TS/MP System Management Manual before formulating your link-configuration strategy. You will likely have to start with an estimate of client demand and server process availability, then fine-tune your configuration as you gain experience.