Patent Application
20070250837
This disclosure relates to computer systems and more particularly to systems and methods for computer workload management.
Currently, computer goal-based workload management systems operate to adjust the CPU in response to an arbitrary measure of performance for any arbitrary workload. The key problem with this is that if a workload is not CPU intensive, the adjustment of CPU may not improve the performance of the workload.
One option is to simply use resource utilization to adjust multiple resources. One problem with this approach is that it may waste resources because some applications may receive performance that far exceeds the requirements for the application. This problem is compounded in that workloads may react differently to the availability of different resources and an adjustment solution must work for any arbitrary workload and it must work for any measure of performance for that workload.
Another issue is that a workload's performance may be impacted by resource contention caused by other workloads. Such contention can cause resource requirements to vary over time based on what the application is doing at the time and on the other applications that are running on the system at that time and what stage such application is in.
In some arrangements, a computer system workload is affected by the amount and type of resources that are available to the workload at any particular time. Thus, when a workload is underperforming it is desirable to adjust the resources that are available to it.
Current systems address a single resource and, hence, require separate resource allocation policies for each computer system resource that can be adjusted. These “single” resource management systems add complexity to defining a resource allocation policy for workload management systems.
Workload management is the approach of adjusting resource entitlements (such as the number of CPUs, the amount of memory, etc.) to workloads based on workload performance data. When multiple resources are being adjusted it is difficult to determine which resource to adjust to achieve optimum results. It is also difficult to know how much a given resource change will improve the performance of the workload.
As an example, if a system is measuring the response time of a workload and it has the ability to adjust the entitlements of, for example, CPU, memory, disk I/O bandwidth or network bandwidth, how does it know which of these should be adjusted to improve the response time of the workload?
There are disclosed systems and methods for coordinating a multi-resource computer system such that demands for resources are arbitrated across all available resources and all applications such that the proper resource will be adjusted to increase the proper workload performance regardless of which resource is needed to improve workload performance. In one embodiment, the system tracks performance data across all resources so that the system knows for all resources what to expect from a resource adjustment at any point in time. Using the system and methods disclosed, any desired resource adjustment is tempered to insure that maximum benefit is derived from such an adjustment. Arbitration is used to mediate between competing resource requests.
In one embodiment, resource allocation vectors are used to determine allocation of resources that will improve a workload's performance. In operation, a measurement is taken for each available resource to determine the enhancement achieved by adding a certain quantity of a resource. In this manner a historical profile is created for a point in time dependant upon the workload's actual response at that time to changes in resource availability. When the performance of a workload requires enhancing by the adjustment of a resource, the historical profile is used as a vector by the workload policy controller to adjust resource to achieve the desired enhanced performance.
In one embodiment, resource consumption and performance data is collected over a period of time and that data is used to adjust resource requests for a workload in order to improve the workload's performance. The resource request is modified to deliver the most workload benefit for each resource modification.
For a more complete understanding of the present invention, reference is now made to the following descriptions taken in conjunction with the accompanying drawings, in which:
WLM tools 13 and 14 are most likely a single instance of WLM and, as will be seen, operate to change the partitions 15-1 to 15-4 for each resource for each application as necessary.
The structure shown in
For discussion purposes, let us assume that resource 11-1 is memory monitored by WLM tool 13 (
Resource requirements can be based on a basic or sophisticated profile based controller algorithm. The resources that a workload (application) has available to it depends upon the workload's utilization of those resources. For example, if the workload is entitled to use 60 shares of CPU and is using 40, that is a 66% utilization of CPU. If the same workload has access to 2 Gigabytes of memory (not shown) and is using 1.5 Gigabytes, that is 75% utilization. If it has access to 2 Gigabytes/sec of network bandwidth and is using 1.9 Gigabytes, that is 95% utilization. A resource manager seeing that utilization is over a certain threshold level might then call for additional resources.
It would be easy to look at these resource requests and assume that because network bandwidth is at 95% utilization the problem is with network capacity. This may or may not be a factor in slower than expected workload processing by calculating individual resource pressure. The system can, based upon a knowledge of how each resource impacts workload performance, adjust a resource request based on the likelihood that the request resource will actually help improve the performance workload. As an example, memory can be at 95% utilization. Adding memory will have no impact on performance since the workload's total data is already in memory. This is in contrast to the CPU rising above 80%, as it starts impacting performance due to process context switching being performed continuously. The time for such processing becomes excessive when CPU utilization goes above 80%.
Based upon the input from process 22-1 and input from process 23-1 which collects the actual resource consumption by application 1, process 25-1 issues commands for adjusting resource requests. These commands are sent to the proper WLM tool (in this case tool 13) to change the partition (15-1,
Process 25-1 adjusts the resource requests (for all resources for application 1) based on the utilization of the same resource in the prior interval and the pattern of how these resources impact performance and sends these requests to resource arbiter 26. This can be done serially on a resource by resource basis, or all at one time, as desired.
Thus, process for resource 11-N (and for any other resource) is the same as for resource 11-1, except performed by processes 21-N through 25-N. Note that while the processes for resources 11-N are shown separately from the processes for resource 11-1, they, in fact could be the same. Also note that while separate processes 21-1 to 25-1 are shown, they could also be a single process or any combination thereof.
The process for application 12-N (and for any other application) is the same as application 12-1, which is performed by processes 21-N through 25-N, such that adjust source request 25-N sends requests for all needed resources (with respect to application N-1) to arbiter 26. Arbiter 26 then determines the mediation between resources and between applications to maximize the overall system operation. Arbiter 26 can work on all resources or on one at a time, as desired.
Note that while the processes for applications 12-N are shown separately from the processes for applications 12-1, they, in fact could be the same and used serially. Also note that while separate processes 21-1 to 25-1 are shown, they could also be a single process or any combination thereof.
Workload manager (WLM) 48, working with policy objects 47-1 to 47-N control the resource allocation in conjunction with process 40, as will be discussed with respect to
In process 402 the WLM determines the proportion (scalar) of the current allocation to reduce by using a previously calculated resource allocation vector (as will be discussed hereinafter). Process 403 calculates the workload allocation to equal the old allocation plus the proportion (resource allocation vector) to reduce or add the needed resources. Process 404 changes the resource allocation for the workload under control of the WLM.
Note that as discussed above, processes 401 through 404 operate on the assumption that an allocation vector has previously been established for the next change to occur. If it is time for reestablishing an updated resource allocation vector, process 405 initiates process 407 which determines the resource type, i.e., CPU memory input/output, bandwidth, etc.
Process 408 removes the target resource to be updated from the list of resource types available. Process 409 changes the allocation of the resource by delta units. Process 410 takes a measurement of the improvement in the workload performance; this is the improvement.
Process 411 then normalizes the scalar by determining that the component equals the delta divided by the improvement. If the improvement is zero, then the component equals the minimum increment for this resource. This means that if there has been no improvement by increasing the resource there is no need to continue to change the resource.
Process 407 then begins a process of iterations such that a different resource component is tested and if there are more resource types to be tested remaining then processes 408, 409, 410 and 411 continue. When all resource types have been tested, process 414 updates each resource allocation factor in the workload policy controller which is part of the WLM.
Note that with processes 407, 408, 409, 410, 411 and 412, each resource in turn is tested to determine what effect a change in that resource will have on the operation (performance) of the workload. Subsequently, this resource allocation vector is used in process 403. This is done after process 402 in which WLM determines the magnitude (proportion) of the change in resource allocation needed by the workload. These settings are then maintained in WLM and used in processes 402, 403 and 404 to set the resource to the proper level when an adjustment in resources is necessary. Thus, in process 401 when the determination is made that a workload performance needs improvement, process 402 looks in its allocation of scalars and determines which scalars to apply to which resources and the resource is adjusted. From prior iterations it was known that a certain adjustment will result in a certain increase and so as a result when a resource is added it is highly likely that performance will be enhanced. Process 406 continues monitoring resource allocation that no updates are taking place.
As discussed above, the initial unit of resource allocation is not critical, since it is the vector that determines which resource should be adjusted and by how much. The system effectively uses pre-profiling of each resource response to a particular workload after a certain period of time, or whenever a given resource allocation reaches its maximum (or minimum), the allocation vector is recalculated directly, as a moving average, or as a smoothed combination of previous vectors.
Thus, as discussed, multiple computer system resources are considered when allocating resources to a workload so that the workload can meet its performance criteria. The systems and methods discussed herein make resource allocation policy definition easier by allowing for a single specification for multiple computer system resources, based on an historical response of the workload to changes in each individual resource allocation to the workload.
As discussed, process 40 can run, if desired, in a global controller (not shown) or in one or more of the resource managers. Process 401 collects resource consumption data by extracting data from the system on a resource by resource basis to determine how much of each resource was consumed by the workload in the prior interval. This data can come from the resource managers or from other sources and can be stored in storage (not shown) if desired.
Process 40 makes it possible to adjust multiple resource entitlements simultaneously and have a reasonable likelihood of making appropriate adjustments that will improve the response time of the workload, without wasting resources that are not likely to improve performance.
