When WLM determines a WLM server-specific recommendation, it determines the service class of the server address space and then assigns a weight that is based on the following criteria:
If the distributor and target systems are not running a release prior to V1R11, you can use the PROCXCOST and ILWEIGHTING parameters on the VIPADISTRIBUTE statement to influence the WLM server-specific recommendation.
For applications that are designed to have a portion of their workload run on a zAAP or zIIP specialty processor, use the PROCXCOST parameter on the VIPADISTRIBUTE statement to influence how aggressively WLM favors servers on systems with available zAAP or zIIP capacity over servers on systems where work targeted for the specialty processors has instead run on the conventional processor. The PROCXCOST parameter specifies a crossover cost in the range 1–100 that is applied to the amount of zAAP-targeted or zIIP-targeted workload that actually ran on the conventional processor. The resulting cost is used to reduce conventional processor use by the application, which in turn reduces the WLM recommendation for that server. A crossover cost of 1 means that zAAP-targeted or zIIP-targeted workload that runs on the conventional processor should not be penalized; the WLM recommendation is not reduced.
Before specifying a high crossover cost, give careful consideration to the effect this might have on workload distribution, because servers with less zAAP or zIIP processor capacity might receive a significantly lower percentage of the overall workload. The RMF™ Workload Activity Report shows the zAAP and zIIP processor use, as well as how much crossover took place. Run this report before and after using the PROCXCOST parameter to better understand how it affects your overall workload performance.
Use the ILWEIGHTING parameter on the VIPADISTRIBUTE statement to influence how aggressively WLM favors servers on systems with displaceable capacity at lower importance levels over servers on systems with displaceable capacity at higher importance levels. Work is categorized into one of seven importance levels (importance levels 0 through 6). The most important work runs at importance level 0 and the least important work runs at importance level 6.
The ILWEIGHTING parameter value specifies how WLM should consider displaceable capacity when determining a server-specific recommendation. The higher the value specified for ILWEIGHTING, the more a stack with displaceable capacity at lower importance levels is favored. The possible ILWEIGHTING parameter values and examples of their effect are as follows:
Specifies that WLM should ignore importance levels when comparing displaceable capacity. This is the default value. For example, if system A and system B are running at 100 percent capacity and new work will be running at importance level 2, all work at importance level 3 and greater is considered to be available displaceable capacity.
The WLM weights are initially the same for both systems, but might be different after the health and performance of the application are considered. The actual WLM weights returned to the invoker are normalized by WLM so that they are in the range 0–64.
In this example, as 100 connections are received, 50 connections are distributed to system A and 50 connections are distributed to system B, assuming that the health and performance of each application are optimal.
Specifies that WLM should weigh displaceable capacity at each successively lower importance level slightly higher than the capacity at the preceding higher importance level. The weighting grows proportionally to the square root of the importance level difference plus 1. This provides a moderate bias when comparing displaceable capacity at different importance levels. Using the previous example but with ILWEIGHTING 1 specified, system B is preferred over system A even though 500 service units of work are to be displaced on either system.
500 × SQUAREROOT ((Importance level of displaced work - Importance level of new work) + 1)
= 500 × SQUAREROOT ((3 - 2) + 1) 500 × SQUAREROOT ((Importance level of displaced work - Importance level of new work) + 1)
= 500 × SQUAREROOT ((6 - 2) + 1)In this example, as 100 connections are received, roughly 39 are distributed to system A and 61 are distributed to system B, assuming that the health and performance of each application are optimal.
Specifies that WLM should weigh displaceable capacity at each successively lower importance level significantly higher than the capacity at the preceding higher importance level. The weighting grows proportionally to the importance level difference plus 1. This provides an aggressive bias when comparing displaceable capacity at different importance levels. Using the original example but with ILWEIGHTING 2 specified:
500 × ((Importance level of displaced work - Importance level of new work) + 1)
= 500 × ((3 - 2) + 1) 500 × ((Importance level of displaced work - Importance level of new work) + 1)
= 500 × ((6 - 2) + 1)In this example, as 100 connections are received, roughly 28 are distributed to system A and 72 are distributed to system B, assuming that the health and performance of each application are optimal; more than twice as many are routed to system B than system A.
Specifies that WLM should weigh displaceable capacity at each successively lower importance level significantly higher than the capacity at the preceding higher importance level. The weighting grows proportionally to the square of the importance level difference plus 1. This provides an exceptionally aggressive bias when comparing displaceable capacity at different importance levels. Using our original example but with ILWEIGHTING 3 specified:
500 × SQUARE ((Importance level of displaced work - Importance level of new work) + 1)
= 500 × SQUARE ((3 - 2) + 1) 500 × SQUARE ((Importance level of displaced work - Importance level of new work) + 1)
= 500 × SQUARE ((6 - 2) + 1)In this example, as 100 connections are received, roughly 14 are distributed to system A and 86 are distributed to system B, assuming that the health and performance of each application are optimal; more than six times as many are routed to system B than system A.
Use the Netstat VDPT/-O report option with the DETAIL modifier to determine the WLM server-specific weight recommendations for each processor type, along with the modified weight for each processor based on the current usage of each processor type.
Evaluate whether WLM server-specific weight distribution can be used as an alternative to WLM system weight distribution for an application. In addition to the reasons mentioned previously, WLM server-specific weight distribution has the added advantage that processor proportions are automatically determined and dynamically updated by WLM based on the actual CPU usage by the application. If you need to determine the processor proportions necessary for WLM system weight distribution, study the workload usage of assist processors by analyzing SMF records, use performance monitor reports such as RMF, and so on.
While WLM server-specific recommendations can be very effective in helping load balancers optimize their routing decisions, there are some scenarios in which applications that are load balancing targets might experience issues that WLM is not aware of through its normal monitoring functions. For example, consider a scenario in which a specific server application instance is executing on a system with excess CPU capacity, yet it cannot successfully process any transactions routed to it because the back-end database it requires on that system is not currently available. From a WLM perspective, this server application instance appears to be a very good candidate to receive requests, given the current available capacity of the system, and the fact that transactions routed to this server appear to be completing very quickly and consuming very little CPU capacity. WLM would therefore assign a higher server-specific weight to this server instance, causing more work to be routed to the ailing server. This type of problem is sometimes referred to as a storm drain problem.
To help alleviate this problem, WLM also considers the health of the server application in its server-specific recommendations. The health of the server is directly determined by information that the server application provides to WLM through programming interfaces. In this way, the WLM perceived health of the application depends directly on the amount of information that an application provides to WLM, if any. WLM uses this information to potentially reduce the weight recommendations for specific server applications that are experiencing problems. This enables sysplex distributor to direct fewer new TCP connections to these servers, selecting instead servers that are not experiencing these problems. WLM considers the following components when determining a server application's health:
This is applicable to applications, such as the CICS® Transaction Server for z/OS®, that act as Subsystem Work Managers, reporting transaction status using Workload Management Services, such as IWMRPT. For example, if an application reports to WLM that 90% of all transactions it processed completed abnormally, this server is probably not a good candidate for receiving many new TCP connection requests, as these requests will likely also complete abnormally. As a result, WLM significantly reduces the weight recommendation that is returned to sysplex distributor for this server.
This health indicator is available only for applications that provide this information to WLM using the IWM4HLTH or IWMSRSRG services. The health indicator provides a general health indication for an application or subsystem. Under normal circumstances, the value of this field is 100, meaning the server is 100% healthy. Any value less than 100 indicates that the server is experiencing problem conditions that are not allowing it to process new work requests successfully. A value of less than 100 also causes the WLM to reduce the recommendation provided to sysplex distributor for this server instance.