Apparatus and method for managing a server workload according to client performance goals in a client/server data processing system

Description Submit all comments and votes

BACKGROUND OF THE INVENTION

The concept of allocating computer system resources to achieve user performance goals is known. For example, U.S. patent application Ser. No. 07/876670, now U.S. Pat. No. 5,504,894 "WORKLOAD MANAGER FOR ACHIEVING TRANSACTION CLASS RESPONSE TIME GOALS IN A MULTIPROCESSING SYSTEM", by D Ferguson et al, filed Apr. 30, 1992 and assigned to the assignee of the present invention, shows a process for calculating performance indexes, selecting goal classes whose performance is to be improved and reallocating resources to equitably improve performance. A problem arises in a client/server environment, in which clients (for example, client transactions) are served by one or more servers and one server typically may concurrently be serving more than one client--where the servers are managed by the operating system separately from the clients. The problem is one of managing the servers to accommodate goals (for example, response time goals) set for the client. While it is possible to envision goals being set for the server, the servers are typically not "visible" to the end users of the system who interact with the system through client transactions, so that associating goals only with the clients is more in keeping with the objective of making goals user-oriented.

In the present invention, performance management to meet goals is extended to the client/server environment where clients having different goals may be served by the same or different servers.

SUMMARY OF THE INVENTION

The present invention allows specification of a performance goal for clients in a client/server data processing system environment and manages the performance of the servers to best meet the performance goals of the clients. Each client may have a different performance goal. Each client may be served by a plurality of servers. Each server may serve a plurality of different clients, and each of the clients served by such a server may have different performance goals.

The importance of achieving a performance goal may also be specified with each performance goal and the servers may serve clients that each have goals with different importances.

Given an awareness of the client performance goals, the operating system takes on responsibility for allocation of system resources to servers of the clients such that the client goals are best achieved. Tradeoffs are made to best utilize the available capacity, based on actual achievement toward goals and the types of resources required to achieve those goals.

BRIEF DESCRIPTION OF THE DRAWINGS

The detailed description explains the preferred embodiments of the present invention, together with advantages and features, by way of example with reference to the following drawings

FIG. 1 is a system structure diagram showing a computer system with its controlling operating system and system resource manager component adapted as described for the present invention.

FIG. 2 shows the server performance block.

FIG. 3 shows the server history block.

FIG. 4 is a flowchart showing the logic for the build topology function.

FIG. 5 is a flowchart showing the overall logic flow in the goal-driven performance-controller component.

FIG. 6 is a flowchart showing logic flow for the select-receiver function.

FIG. 7 illustrates the state data used to select resource bottlenecks.

FIG. 8 is a flowchart showing logic flow for the find-bottleneck function.

FIG. 9 is a flowchart showing logic flow for the fix function.

FIG. 10 is an illustrative graph showing proportional aggregate speed versus performance index.

FIG. 11 is a flowchart showing logic flow for the select-donor function.

FIG. 12 is a flowchart showing logic flow for the assess-net-value function for contemplated changes.

FIG. 13 is a flowchart of the steps to assess improving performance by increasing dispatch priority.

FIG. 14 is a flowchart showing logic flow for projecting the effects of changing dispatching priorities.

FIG. 15 is an illustrative graph showing achievable demand and a table of the data points used in the preferred embodiment.

FIG. 16 is a flowchart for calculating a new wait-to-using ratio.

FIG. 17 is a flowchart for calculating CPU time using sample deltas.

FIG. 18 is a flow chart showing logic flow to reduce auxiliary storage paging delay.

FIG. 1 is an illustrative work unit paging graph.

DETAILED DESCRIPTION OF THE INVENTION

FIG. 1 illustrates the environment and the key features of the present invention. (The present invention is related to the invention described in U.S. Patent Application "APPARATUS AND METHOD FOR MANAGING A DATA PROCESSING SYSTEM WORKLOAD ACCORDING TO TWO OR MORE DISTINCT PROCESSING GOAL TYPES", by J. D. Aman et al, filed on an even date herewith and assigned to the assignee of the present invention. It is incorporated by reference hereby.) A computer system (100) is controlled by an operating system (101) such as IBM's MVS/ESA in the preferred embodiment. A dispatcher (102) is a component of the operating system that selects the unit of work to be executed next by the computer. The units of work (150) are the server programs that do the useful work that is the purpose of the server computer system. The server programs do work for and on behalf of the clients (155) in a client/server system. The clients (155) are either end users at terminals or programs executing in other computer systems. Typically, clients (155) are attached to a server computer system by communication links. Clients (155) generate messages (transactions) that are sent to the server computer system to convey the work request to a particular server. The transactions are routed to different servers for action, depending on the specific work that is requested. Performance goals are set for the clients (155); however, the performance results are a function of the servers (150) performance when doing work for the clients. The clients having the same performance goal are said to be in the same class for performance management purposes. Two data structures provide the means for relating the performance of a server work unit (150) to a client (155). A server performance block (SPB) (151) contains the identifier (FIG. 2 201) of the client performance goal class of a client currently being served by the server work unit. If more than one client is being served concurrently, then there is a server performance block for each such client. A server history block (SHB) (152) has space for an entry (FIG. 3 301) for each performance goal class defined to the system. Each such entry contains a count of the number of times the server was recently observed to be serving a client of the corresponding performance goal class.

The server units of work that are ready to be executed are represented by a chain of control blocks in the operating system memory called the address space control block (ASCB) queue (103). Each ASCB has a field that contains a relative importance (dispatching priority) value (104). The dispatching priority is adjusted by operation of the present invention and used by the dispatcher to select to be executed the highest priority unit of work from those that are ready to be executed, as determined by the ASCB queue. The dispatching priority is the most important controlled variable provided by the present invention for meeting the stated performance goals for computer system operation.

The present invention takes as input the performance goals for clients (transaction generators) These performance goals are established by a system administrator and stored (141) on a data storage facility (140). The performance goals are established in terms of transaction response time (in seconds) for each client. Included with the performance goals is the specification of the relative importance of each goal. The goals (141) are read into the system by a workload manager (WLM) component (105) of the operating system. Each of the goals specified by the system administrator causes the workload manager to establish a performance class to which individual clients will be assigned. Each performance class is represented in the memory of the operating system by a class table entry (106). The specified goals (in an internal representation) and other information relating to the performance class are recorded in the class table entry. Among the more important information stored in a class table entry is response time goal (110) (an input value), the relative importance (108) (an input value), and the performance index (109) (a computed value).

A system resource manager (SRM) component (112) of the operating system is modified according to the present invention to include a goal-driven performance-controller (GDPC) component (114) and to operate in the following manner as shown in FIG. 1. The GDPC performs the functions of measuring the achievement (109) of client performance goals (110) by monitoring server (150) performance on their behalf, selecting the client performance goal classes that are not meeting their goal, and (indirectly) improving the performance of the selected client transactions by improving the performance of the server work units (150) that have been observed to have served the selected clients. The GDPC function is performed periodically based on a timer expiration approximately every ten seconds.

At (115), a performance index is calculated for each client performance goal class table entry (106) using the specified goal (110). The resulting performance index is recorded in the corresponding class table entry (106) at (109). The concept of a performance index as a method of measuring client performance goal achievement is well known. For example, in the U.S. Patent Application cited earlier: "WORKLOAD MANAGER FOR ACHIEVING TRANSACTION CLASS RESPONSE TIME GOALS IN A MULTIPROCESSING SYSTEM" the performance index is described as the actual response time divided by the goal response time.

At (116), a client performance goal class is selected to receive a performance improvement based on the goal (110), the relative goal importance (108) and the current value of the performance index (109). The selected client performance goal class is referred to as the receiver goal class.

Client/server relationships are determined by sampling the server performance blocks (151) and recording the result in the server history block (152). The client/server topology is built (126) by extracting from the server history blocks (152) for all the servers (150) the list of client goal classes that have been recently served (that is, the sampling period set for the build topology function, described later). The list is inverted so that the result is, for each goal class, a list of the servers used by the clients assigned to that class. Client goal class server lists that contain identical lists of servers are combined since, from a performance-management standpoint, they are indistinguishable. Each of these resulting server lists forms the basis of a server class table entry (127).

The resulting server class table has an entry (127) for each unique combination of servers and client goal classes. If necessary, the server class table is reconstructed periodically to accommodate changes in the client/server relationships that may occur over time. In the preferred embodiment, for example, the server class table is reconstructed every minute.

Once the receiver goal class has been selected, a corresponding server class is selected to receive the benefit of the resource actions. The server class performance bottleneck is determined (117) relative to the controlled variables by using state samples (125), a well known technique. The controlled variables are protective processor storage target (133) and dispatch priority (104).

At (118) the potential changes to the controlled variables are considered. A client performance goal class is selected (123) for which a performance decrease can be made based on the relative goal importance (108) and the current value of the performance index (109). The selected client performance goal class is referred to as the donor. The corresponding server class determines which server(s) will potentially donate resources to the receiver server(s). Next, the contemplated changes are assessed (119) for net value relative to the expected changes to the performance index for both the receiver and the donor. That is, if the result will yield more improvement for the receiver than harm to the donor relative to the goals, then one or more of the following controlled variables is adjusted: dispatch priority (120) (104) and the swap protect time target (132) for both the donor and the receiver.

The goal driven performance controller (GDPC) function is performed periodically, for example once every ten seconds, and is invoked via a timer expiration. The functioning of the GDPC provides a feedback loop for the incremental detection and correction of performance problems so as to make the operating system adaptive and selftuning.

Each server work unit has one or more performance blocks and a server history block. A performance block contains an identifier for the transaction class the server is serving. If a server is serving multiple transactions at a given time, the server will have multiple Performance Blocks.

FIG. 2 shows the server performance block (151) in more detail. The server performance block contains the identifier (201) of the client performance goal class for which the server is currently performing service. If the server is currently performing service for more than one goal class, then there is an instance of the server performance block for each goal class being concurrently served.

The client/server relationship are determined by sampling. The number of observations when a particular server is observed to be serving a particular performance goal class is recorded in the server history block for that server. FIG. 3 shows the server history block in more detail. Each server's Performance Blocks are sampled periodically, for example, four times a second in the preferred embodiment, and the observations are recorded in the associated server history block in the entry that corresponds to the performance goal class.

BUILD TOPOLOGY

FIG. 4 illustrates building the client/server topology (126). At (401), a set of client/server observations is built for each server from the observations collected in the server history block. The sample set is built from samples collected over a long enough time interval to get a representative picture of which client classes the server is serving. This time interval may vary depending on activity but is generally in the range of several minutes.

At (402), a list is built of the servers serving each client class. At (403) duplicate sets of servers are eliminated resulting in the minimum set of server classes needed. All the servers that serve exactly the same set of client classes are grouped in single server class for management purposes.

At (404) a check is made to determine whether the correct set of server classes has already been built. This is the normal case because the client/server relationships are reassessed relatively frequently, approximately once a minute. If the current set of server classes does not reflect the current client/server topology, server classes are added or deleted as needed at (405). Then, at (406), servers are moved to the new server classes to be managed to their client's goals.

PRIMARY PROCESSING STEPS

FIG. 5 is a flowchart showing the logic flow for the primary processing steps of the present invention. At (501), a performance index is calculated for each client performance goal class and the current values are calculated for the proportional aggregate speed graph (FIG. 10) and the work-unit-paging graph (FIG. 19). The performance index calculation is described later. At (502), a client performance goal class, referred to as the receiver, is selected to have its performance improved. The selection process is shown in more detail in FIG. 6. Once the receiver goal class is selected, a corresponding server class is selected as the receiver server class. At (503), one of the receiver server class resource bottlenecks is selected as the bottleneck to address. Bottleneck selection is shown in more detail in FIG. 8. At (504), server classes that own the resource identified as required to improve the performance of the receiver goal class are selected. These selected server classes are referred to as donors. Donors are selected in reverse order to receivers, that is, the server classes are selected that correspond to the client goal classes having the best performance indexes and least importance. Donor selection is shown in more detail in FIG. 11.

At (505) the effects of the resource reallocation from the donor to the receiver are projected. The algorithms used to project the effects of resource reallocation depend on the resource involved.

At (506), the net value of reallocating the resource from the donor or donors to the receiver is assessed. A receiver will only be improved by reallocating resource from a specific donor if there is projected to be net value to the resource reallocation. If using a donor to improve a receiver is projected to result in more harm to the donor than improvement to the receiver relative to the goals and importance, the resource reallocation is not done. Net value assessment is shown in more detail in FIG. 12.

If there is net value to the reallocation, the resources are reallocated from the donor or donors to the receiver at (507). If there is not net value, a check is made at (508) to determine whether there is another potential donor.

If there is another potential donor, control passes to (504) to select another potential donor. If there are no more potential donors of the resource required to address the selected bottleneck, a check is made at (509) to determine whether the receiver has another bottleneck.

If the receiver has another bottleneck that can be addressed, control returns to (503) to select another bottleneck. If the receiver has no more bottlenecks to address, a check is made at (510) to determine whether there is another potential receiver goal class.

If there is another potential receiver goal class, control returns to (502) to select another potential receiver goal class. If there are no more potential receivers, the goal driven performance controller function is complete for the present iteration (511).

The GDPC function is invoked again when the periodic timer next expires, providing feedback on the effect of the resource reallocations made previously and again providing the opportunity to address performance problems.

PERFORMANCE INDEX

The performance index is calculated for response time goals (115) as follows:

(performance index)=(actual response time)/(response time goal)

The performance index is actual response time divided by the response time goal for client performance goal classes.

A performance index of 1.0 indicates the client performance goal class is exactly meeting its goal. A performance index greater than one indicates the class is performing worse than its goal, and a performance index less than 1.0 indicates the class is performing better than its goal.

For response time goals, the performance index is calculated from enough recent response completions to be representative of the results for the class. For example, the preferred embodiment takes samples for thirty seconds or accumulates ten samples, whichever is less.

SELECT RECEIVER TO IMPROVE

FIG. 6 shows a flow chart of the logic flow for selecting a performance goal class to receive a performance improvement (116). At (601) the performance goal class table is searched to determine whether any entries have an associated importance value. Importance values are optional when specifying the performance goals. If no importance values have been specified for any of the goal classes, the goal class having the worst (highest) performance is selected (602). If importance values have been specified, the importance value to be considered is initialized to the highest importance value specified for any performance goal class (603). At the importance being considered, all performance goal classes having that importance are assessed for underachieving their respective performance goal (604). The worst underachiever at the importance value being considered, if any, is selected as the receiver (605). If there are no underachieving performance goal classes at the importance being considered (604), then if another, lower importance value has been specified (606), the next lower importance value specified is set to be considered (607) and control returns to (604). If there are no underachieving performance goal classes at all, then the worst-performing performance goal class is selected as the receiver (602), as if no importances were used.

FIND BOTTLENECK

In the present invention, both a bottleneck (target) server and a bottleneck (target) resource must be selected. That is, a target server is selected by apportioning delay samples among the servers serving the selected client goal class, and a target resource is also selected by apportioning, both as described later in this specification.

DATA FOR FIND BOTTLENECK

FIG. 7 illustrates the data used to select the server and resource bottlenecks to address. For each server/delay combination, n, the data contains the number of server Sn (702), delay type Dn (704), samples apportioned to the selected receiver (client) goal class (701), and a flag indicating whether the server/delay combination has already been selected as a bottleneck for the receiver goal class in question during the current invocation of the goal driven performance controller (703).

FIND BOTTLENECK OPERATION

FIG. 8 illustrates the operation of the find bottleneck function (117). Find bottleneck operates on a server class that corresponds to the selected receiver goal class. The selection of bottleneck to address is made by selecting the server/delay combination with the largest number of samples that has not already been selected during this invocation of the GDPC. When a server/delay combination is selected, the flag is set so the server/delay combination is skipped if the find bottleneck function is reinvoked for this receiver during the current invocation of the GDPC.

At (801), the proportion of time each server serves each client goal class is calculated. This proportion is equal to the number of times server Sn was observed serving client class Cn divided by the total observations of that server serving any client. Since the client/server relationships may not be static, samples are aged out after a few minutes so that the client/server proportions change as client/server relationships change.

At (802), each server's delay samples are apportioned to each client class in proportion to the time the server is serving the client class. Therefore, the number of samples (701) for delay type Dn apportioned to client class Cn from server Sn are that server's total samples of delay, times the proportion of time server Sn is observed serving client class Cn.

At (803), the delay type having the largest number of samples apportioned to the receiver goal class is selected as the resource bottleneck delay type to be addressed on behalf of the receiver goal class. At (804), the server that experienced the bottleneck delay is selected as the bottleneck server.

FIXING DELAY

This section describes how the receiver performance goal class performance is improved by changing a controlled variable to reduce the delay selected by the find bottleneck function.

GENERAL FIX FLOW

FIG. 9 illustrates at a high level a flow chart of the steps required to assess improving a receiver goal class performance by changing the controlled variable related to the chosen resource bottleneck (118). At (901), a new value is chosen for the controlled variable. At (902), the change to the performance index is calculated for the receiver performance goal class. The details of this calculation are specific to individual resources and are described below. At (903), the improvement in the performance index is checked to determine whether the change results in sufficient value to the receiver goal class. If there is not sufficient receiver value, control returns to (901) where a value is chosen for the controlled variable that will result in greater benefit for the receiver goal class.

When there is sufficient receiver value, control passes to (904) where select donor is called to find donors of the resource needed to make the control variable change. At (905), a check is made to determine whether the contemplated change has net value. For the contemplated change to have net value, the benefit to the receiver goal class in relation to goals and importance must be more than the harm to the donor goal class(es). If the contemplated change does have net value, the controlled variable is changed at (906). If there is not net value, the chosen resource bottleneck cannot be fixed (907).

PERFORMANCE INDEX DELTA

The performance index value for a client performance goal class is the measure of how well that goal class is meeting its specified goal. The measure of whether a contemplated resource reallocation has value to the receiver goal class is the projected change in the performance index (index delta) of the receiver goal class that occurs as a result of the contemplated resource reallocation. Similarly, the measure of the net value of a contemplated resource reallocation is the improvement in the index delta of the receiver goal class relative to the degradation of the index deltas of the donor goal classes.

PROPORTIONAL AGGREGATE SPEED

In the client/server system of the present invention, improving the performance of a server will only improve the performance of a client performance goal class in proportion to the extent to which the server serves clients assigned to that client performance goal class.

In this invention, we introduce the concept of proportional aggregate speed for a client performance goal class. The proportional aggregate speed of a client goal class is the apportioned speed of all the servers serving it. The proportional aggregate speed for each client goal class is determined by allocating all of the client's server's state samples to the client performance goal class in proportion to the number of times each server was observed serving each client goal class. These are the samples shown in FIG. 7 (Data For Find Bottleneck).

The proportional aggregate speed of a client performance goal class is defined as the total CPU-using samples apportioned to the client performance goal class from all servers (that is, the servers in the corresponding server classes), divided by the total CPU-using plus all delay samples apportioned to the client performance goal class from all servers. Proportional aggregate speed is calculated for each client goal class as follows: ##EQU1##

PROPORTIONAL AGGREGATE SPEED GRAPH

The proportional aggregate speed graph, illustrated in FIG. 10, is introduced for the purpose of projecting performance index deltas in a client/server environment. The proportional aggregate speed graph is represented in computer memory by a table of calculated proportional aggregate speed and the corresponding calculated performance index pairs of values, arranged in proportional-aggregate-speed order.

When a performance index must be projected for a contemplated resource reallocation, a new proportional aggregate speed is calculated from the projected new delays for the servers with respect to the reallocated resources. and the new, projected performance index is read or interpolated from the table (that is, "read from the graph").

SELECT DONOR

FIG. 11 is a flowchart showing logic flow for the select-donor function (123). The purpose of the select-donor function is to choose from the set of goal classes the most eligible goal class to have its performance reduced in favor of the receiver goal class. These