CN101154279A - 自动管理事务处理工作负荷的资源消耗的方法和装置 - Google Patents

Abstract

本发明涉及一种在计算机系统(100)中进行工作负荷管理的方法，其中将工作单元(152)组织成业务类(121)，向所述类提供特定量的系统资源(140)，并且其中将多个业务类周期(122)与每个业务类(121)关联，其特征在于，确定至少一个当前业务类周期(122)内的工作负荷行为，以及根据所述确定的工作负荷行为来自动调整可用业务类周期(122)的数量。

Description

自动管理事务处理工作负荷的资源消耗的方法和装置

技术领域

本发明涉及自动管理事务处理工作负荷的资源消耗的方法和装置。

背景技术

工作负荷管理器是一种软件组件，其根据隐式或显式定义竞争工作项之间的相对优先级的性能准则，管理将可用于每个执行工作项的计算机系统的系统资源。性能准则可以例如是用户定义的目标。换言之，工作负荷管理根据反映工作负荷需求和用户期望的目标定义来针对入站工作调整系统资源。一个特别的关注点在于事务处理工作负荷，其通常代表需要在短时间内完成的重要且短期运行的最终用户请求。

在工作负荷管理期间，将由操作系统管理的工作单元组织成不同的类(称为业务类或资源类)。换言之，每个工作单元都与业务类(例如，联机事务、高优先级批处理、低优先级批处理等)关联。为每个业务类提供特定量的系统资源。

在此上下文中使用的术语工作、工作单元、工作的单元、工作业务单元和事务是可互换的，并用于代表对计算机系统的有用的用户定义的处理。由计算机系统的用户应用的特定术语取决于系统类型、公共术语(包括作业、任务、进程、线程等)。

每个业务类都带有一组参数，所述参数向工作负荷管理器指示关联的工作单元的性能准则。因此，如果工作负荷管理器注意到分配给给定业务类的工作单元的资源总是无法使该业务类的工作单元满足其性能准则，则工作负荷管理器可以调整分配给该业务类的工作单元的资源。例如，将资源从施主业务类重新分配到受主业务类，如果此类重新分配带来的受主业务类的性能改进超过了施主业务类的性能降低的话。简言之，如果存在由预定性能准则确定的性能上的净正效应，则发生重新分配。资源的分配不仅由其对工作单元(向其重新分配资源)的影响决定，而且由其对工作单元(从其取走资源)的影响决定。

每个业务类都与性能目标和重要性级别关联。业务类的重要性级别定义了在系统处于争用状态以致不能实现某些业务类的性能目标的情况下，计算机系统处理该业务类中的工作的方式。在这种情况下，计算机系统将忽略具有低重要性级别的业务类的性能目标。

与业务类关联的工作将消耗计算机系统资源。当工作不是同类的且在其执行时间和资源消耗上表现出很大的变动(例如，如果执行少量请求的时间大大高于平均值且同时消耗太多系统资源)时，将出现问题。结果，其他正在系统上运行的工作会受到这些长时间运行的高资源消耗工作的负面影响。

在一些工作负荷管理环境中(例如，IBM z/OS工作负荷管理器)，可以将多个周期与每个业务类关联，由此定义了当工作处理时间长于预期时工作的行为方式。然后，当用户请求消耗了多于当前业务类周期所允许的系统资源时，则将其从一个业务类周期切换到另一个业务类周期。较低的业务类周期通常以较低的重要性和目标级别运行，以便减轻长时间运行的请求对其他共享同一计算机系统资源的工作负荷的影响。换言之，通过定义其他业务周期，降低长时间运行和高资源消耗工作的目标是可能的。

主要的问题在于定义业务类周期，以便适当地分散工作，使其对其他工作负荷的影响最小化，并确保足够快速地完成重要的请求。从现有技术可知，由操作系统中的管理组件预定义一组固定周期或由计算机管理员或其他人员手动定义和修改该业务类周期。如果一组固定周期具有周期可能没有最佳地配合工作负荷特性的问题，则工作不会最佳地分散在周期之间。对周期的手动修改要求对计算机系统的持续而昂贵的监督和对系统性能数据的分析。

发明内容

本发明的目标是提供一种较简单且带来更佳计算性能的工作负荷管理技术。

根据本发明，通过一种计算机系统中的工作负荷管理的方法来实现此目标，

其中将工作单元组织成业务类，向所述业务类提供特定量的系统资源，以及

其中将多个业务类周期与每个业务类关联，

其特征在于：

确定至少一个当前业务类周期内的工作负荷行为，以及

根据所述确定的工作负荷行为来自动调整可用业务类周期的数量。

根据本发明，通过一种在计算机中执行的数据处理程序来实现此目标，所述数据处理程序包括软件代码部分，当所述程序在所述计算机上执行时，所述软件代码部分用于执行根据本发明的方法。

根据本发明，通过一种存储在计算机可用介质上的计算机程序产品来实现此目标，所述计算机可用介质包括计算机可读程序装置，当所述程序在计算机上执行时，所述计算机可读程序装置用于使所述计算机执行根据本发明的方法。

根据本发明，通过一种计算机系统的工作负荷管理器来实现此目标，

其中将工作单元组织成业务类，向所述业务类提供特定量的系统资源，以及

其中将多个业务类周期与每个业务类关联，

其特征在于，所述工作负荷管理器包括：

用于确定当前业务类周期内的工作负荷行为的装置，以及

用于根据所述确定的工作负荷行为来自动调整可用业务类周期的数量的装置。

本发明的基本思想是自主地将业务类分解为多个业务类周期。在本发明中，无需任何对业务类周期的手动定义。与来自现有技术的公知解决方案相比，本发明较简单并带来了更佳的计算性能，而无需对计算机系统进行持续和昂贵的监督及对系统性能数据进行分析。

本发明描述了自主控制信息处理系统中的事务处理工作负荷的资源消耗以便改进系统吞吐量的方法。所述方法假设业务类定义有重要性和目标以控制事务处理工作负荷的资源消耗。这些业务类中的每个类都初始地与一个业务类周期关联。此外，存在工作负荷管理器，其将资源分配到该业务类周期，以使在该业务类中运行的工作实现指定的目标。如果系统处于争用状态，则假设具有较高重要性的业务类周期将获得对资源的优选且由此更佳的访问。

本发明基于这样的假设：诸如响应时间和资源消耗的事务特性提供了与业务类周期中的事务的最佳分布有关的信息。此类信息的历史用于自主地确定业务类周期的最佳数目及其持续时间以提高整体系统吞吐量。

所述新的方法基于工作负荷管理系统理解用户请求何时开始及何时结束的假定。对于通知工作负荷管理系统有关入站和结束事务的测量工作负荷来说通常是这种情况。根据此信息，工作负荷管理系统获知在业务类中运行的工作请求的特性。工作负荷管理系统确定事务在系统中运行多长时间及其消耗多少资源。根据此信息，工作负荷管理器决定需要多少资源来完成大多数短时运行的事务及系统中长时间运行的事务的成本，即，资源消耗。如果这些成本过高，则工作负荷管理器将长时间运行的事务移动到具有较低性能目标的新业务类周期中。

本发明涉及自主创建业务类周期的技术。如果如所描述的创建业务类周期，则可以通过这样的方式来管理事务处理工作负荷的资源消耗：使短时运行的事务能够快速完成而长时间运行的事务将降级，以便不会危害系统中的其他工作和短时运行的事务。也就是说，本发明讨论了自动创建业务周期并自动将长时间运行的工作与较低业务目标相关联的机制。所述机制自主地创建此类业务周期并在不再需要它们时将其删除。该方法可用于面向目标以及面向资源的工作负荷管理系统。本发明还涉及一种技术，它不仅创建和删除业务类周期，而且还根据确定的工作负荷行为来自动调整业务类周期的特性。具体地说，根据工作负荷特性来设置每个创建的业务类周期的重要性级别和/或性能目标。

此新技术的主要优点是无需手动的业务类周期配置且工作负荷管理系统能够立即对实际的工作负荷行为做出反应。对于具有高负荷的业务类，学习周期将很短且调整将立即提高系统的吞吐量。结果，该装置具有较低的管理成本及更自主的环境。

本发明可以采取完全硬件实施例、完全软件实施例或包含硬件和软件元素两者的实施例的形式。在一个优选实施例中，本发明以软件实现，所述软件包括但不限于固件、驻留软件、微代码等。

此外，本发明可以采取可从计算机可用或计算机可读介质访问的计算机程序产品的形式，所述计算机可用或计算机可读介质提供了可以被计算机或任何指令执行系统使用或与计算机或任何指令执行系统结合的程序代码。出于此描述的目的，计算机可用或计算机可读介质可以是任何能够包含、存储、传送、传播或传输由指令执行系统、装置或设备使用或与所述指令执行系统、装置或设备结合的程序的装置。

所述介质可以是电、磁、光、电磁、红外线或半导体系统(或装置或设备)或传播介质。计算机可读介质的实例包括半导体或固态存储器、磁带、可移动计算机盘、随机存取存储器(RAM)、只读存储器(ROM)、硬磁盘和光盘。光盘的当前实例包括光盘-只读存储器(CD-ROM)、光盘-读/写(CR-R/W)和DVD。

适合于存储和/或执行程序代码的数据处理系统包括至少一个通过系统总线直接或间接连接到存储器元件的处理器。所述存储器元件包括在程序代码的实际执行期间采用的本地存储器、大容量存储装置以及提供至少某些程序代码的临时存储以减少必须在执行期间从大容量存储装置检索代码的次数的高速缓冲存储器。

输入/输出或I/O设备(包括但不限于键盘、显示器、指点设备等)可以直接或通过中间I/O控制器与系统相连。

网络适配器连接到系统以使数据处理系统能够通过中间专用或公共网络变得与其他数据处理系统或远程打印机或存储设备相连。调制解调器、电缆调制解调器，和以太网卡只是几个当前可用的网络适配器类型。

附图说明

现在将参考附图说明本发明的实施例，这些附图是：

图1示出了以存储桶(bucket)分隔的响应时间；

图2示出了具有工作负荷管理器的计算机系统；

图3示出了子系统或应用与工作负荷管理器之间的交互；

图4示出了响应时间分布的图；

图5示出了响应时间分布存储桶中的每事务的CPU消耗；

图6示出了根据本发明的方法的流程图；以及

图7示出了业务类周期的CPU消耗和已结束事务的总数。

具体实施方式

首先，说明了根据本发明的方法的基本原理。本发明基于这样的假设：适于实现本发明的装置(即，组合的硬件和软件)定义了具有重要性和目标的业务类，这将在下文详细说明。这些业务类中的每个类都初始地与一个业务类周期相关联。工作负荷管理器以在业务类中运行的工作实现指定目标的方式将资源分配到这些业务类周期。如果系统处于争用状态，则假定具有更高重要性的业务类周期将首先获得资源。将业务类分解为多个业务类周期通过一种机制自主地完成，所述机制可以分为以下通过工作负荷管理器定期执行的步骤。

步骤1：确定工作负荷行为。对于该步骤，工作负荷管理器必须知道在业务类中运行的工作请求的资源消耗。

步骤2：决定何时创建新的业务类周期。

步骤3：定义新的业务类周期。当创建了新的业务类周期时，向其分配性能目标并将业务类周期切换条件分配给先前的业务类周期。然后，该机制开始下一循环以监视新的业务类周期。

因此，该机制允许在没有足够工作量与业务类周期关联时删除该业务类周期(步骤4)。

为了了解在业务类周期中运行的工作请求的资源消耗，工作负荷管理器适用于捕获在业务类中运行的工作请求的开始和结束。对于所有测量应用而言这通常是可能的。此类测量应用是可能的，例如，通过Open Group的应用响应测量(ARM)标准或通过操作系统的固有装置，例如，z/OS上的自带服务。结果，工作负荷管理器捕获由业务类的过程执行的请求量并能够测量此类请求的资源消耗。

为了理解工作负荷的行为方式，有必要区分长时间运行的事务和短时间运行的事务。出于这种目的，工作负荷管理器必须按照其执行时间来将事务分类。作为起点，工作负荷管理器利用平均事务完成时间，然后，在其周围创建一组存储桶来捕获事务的资源消耗。每个存储桶都代表其中事务已经结束或正在运行的时间周期。这些存储桶的资源消耗创建了一种分布，其允许工作负荷管理器确定在何时需要新的业务类周期。

图1示出了响应时间存储桶10、20中工作负荷的响应时间“t”的可能分隔。在确定了平均响应时间值“Avg”之后，工作负荷管理器在该平均值“Avg”周围创建第一组1等距响应时间存储桶10并创建第二组2非等距存储桶20来捕获界外值。优选地，分布随时间改变以识别工作负荷行为变化。该方法允许创建针对面向吞吐量的目标管理的工作的响应时间分布。

当针对响应时间目标管理业务类时给出了此类分布的另一个更简单的起点。在这种情况下，将响应时间值用作分布的中点，并且根据该值创建响应时间分布。

在定义了响应时间分布之后，可以捕获完成的事务的资源消耗。此外，可以始终估算分布中未完成事务的资源消耗。未完成事务是尚未结束的事务。为了保持连续的图像，将定期捕获未完成的事务并在数个时间周期上保持分布。分析先前的时间周期以理解瞬间的工作负荷行为以及有足够的历史数据可用以便通过工作负荷管理器做出决定。

在解释了本发明的基本原理之后，现在将说明执行根据本发明的方法的计算机系统100的实例。如图2所示的计算机系统100正在执行工作负荷并由操作系统101控制。在示出的实施例中使用了IBM z/OS操作系统。除了与本发明相关的增强，计算机系统100是在申请序列号US 08/383,168中公开的系统。

虽然未在图2中示出，但是计算机系统100可以是被类似管理并组成综合体(sysplex)集群的多个互连系统之一。在美国专利No.5,974,462中说明了总体服务器管理概念，除了与本发明相关的增强以外。

在本实施例中，工作负荷管理器110是操作系统101的整体组件。但是，工作负荷管理器110也可以实现为外部单元，连接到操作系统101并与其协作。具有工作负荷管理器110的操作系统101适于执行本发明的方法步骤。

工作负荷管理器110根据由装置(例如用户)定义的业务定义11来操作。由工作负荷管理器110在系统激活期间从操作系统101外部提供的外部数据集来读取业务定义111。业务定义111包含有关业务类121和业务目标123的详细信息。业务类121组织在业务类表120中，表120是由工作负荷管理器110做出的决定的数据基础的内部表示。

将每个业务类121分成业务类周期122。每个业务类周期122都与业务目标123关联。业务目标123可以是基于响应时间124的目标或是基于执行速度125的面向吞吐量的目标。此类面向吞吐量的目标被称为执行速度目标。响应时间124是其中工作单元平均应结束的时间或规定百分比的工作单元应结束的时间。当在系统中移动时，允许遇到对应于可接受的延迟工作的执行速度125。

每个业务类周期122还与重要性级别126关联。根据重要性级别126，工作负荷管理器110在系统资源变得匮乏时决定哪些业务周期122需要优先对待。

为了确保工作只能消耗特定量的资源，每个业务类周期122都与持续时间127相关联。根据使用的操作系统的种类以可消耗资源单位来定义持续时间127。在使用IBM z/OS的情况下，此类资源单位被称为业务单位，其允许将处理器、存储和I/O消耗正规化为可消耗资源单位。如果业务类121仅包括一个业务类周期122，则省略持续时间定义并因此为无穷大。同一情况适用于业务类121的最后一个周期。

业务周期122还包括样本和管理数据128，其在计算机系统100的运行时期间使用以确定目标实现和将工作单元从业务类周期切换到业务类周期。

工作业务单元152由操作系统用户150(即，在计算机系统100中执行并由操作系统控制的应用或子系统151)来标识。子系统151使用一组到工作负荷管理器110的预定接口来将新的工作单元152与业务类121相关联，这将在下文中详细说明。

工作负荷管理器110始终收集有关操作系统资源140的数据。在本发明的上下文中，最感兴趣的数据是中央处理单元(CPU)的资源141。工作负荷管理器110由数据采样器160协助，数据采样器160收集资源数据并由此生成业务类周期的样本和管理数据128。

工作负荷管理器110使用收集的样本和管理数据128来做出决策并影响工作对资源的访问，即，控制工作单元152对操作系统资源140的访问。决定工作单元152的访问的这些步骤在目标管理设备130中执行，该设备协助工作负荷管理器110。数据采样器160和目标管理设备130可以实现为工作负荷管理器110的一部分或实现为密切与工作负荷管理器110协作的外部单元。

图3说明了子系统(例如，CICS、IMS、Websphere等)或应用200与操作系统101的工作负荷管理器110之间的交互。当新的工作请求到达时，它由应用200中的进程或线程201执行。在第一步骤中，通知工作负荷管理器110新的工作单元152到达。为此，工作负荷管理器110定义了一组应用接口，它们实现为工作负荷管理器110的一部分。这些应用接口适于向工作负荷管理器110提供有关新工作请求的到达的信息。所述应用接口还适于向工作请求提供属性，所述属性允许工作负荷管理器110对工作请求分类，以确定当前针对工作请求工作的线程并通知工作负荷管理器110工作请求何时已结束。

然后，工作负荷管理器110创建工作单元152的内部表示211。该内部表示211有时被称为包含体(enclave)。通过分类过程，将工作单元152与业务类121相关联。在执行期间，工作单元还与业务类周期122相关联，以确保朝向当前目标来管理工作单元。

数据采样器160不断收集状态数据212，状态数据212与工作单元152关联并在业务类周期122的状态数据存储桶223中的同一业务类周期122关联的所有工作单元152间汇总，参见下文。

除了其他资源消耗数据，向具有响应时间目标的业务周期122提供了响应时间分布224。通过工作负荷管理器110根据业务类周期122的响应时间目标来作为起点动态地创建响应时间分布224。

图4示出了响应时间分布400的总体分布。示出的实施方式包括28个存储桶40。存储桶40由工作负荷管理器110通过以下计算来创建：

且

也就是说，如果已结束事务的测量响应时间(rt)小于或等于业务类中事务的目标值的一半，则存储桶数为“1”，并且如果已结束事务的测量响应时间(rt)大于业务类中事务的五倍目标值，则存储桶数为“28”。

因此第一个存储桶41与很短时间运行的事务相关。第八个存储桶42对应于平均响应时间。在目标值周围结束的事务对应于在第二及第二十个存储桶之间的范围43。长时间运行的事务对应于存储桶21与27之间的范围44。最后一个存储桶45与很长时间运行的事务相关。

应注意的是，该分布400仅为实例且可以使用在期望值附近对数据进行分类的任何类似的分布。

虽然如图4所示的现有分布仅收集业务类周期122的结束事务及未完成事务的数量，但是借助工作负荷管理器110可以通过以下方式修改分布400：

对于所有类型的面向目标的业务类周期122，只要业务类周期122与工作单元152的表示211关联，就生成响应时间分布。因为工作负荷管理器110了解该关系，所以也总是可以测量此类业务类周期122的响应时间“rt”，即使已定义了执行速度目标。

对于具有执行速度目标的业务类周期122，使用在例如三十分钟时间段期间结束的事务的平均响应时间。由工作负荷管理器110将该值设置为等于响应时间目标值，以便创建响应时间分布。由工作负荷管理器110定期调整该值并相应地调整分布。

对于具有响应时间目标的业务周期，不断使用响应时间目标来创建响应时间分布。将CPU消耗添加到分布，以便跟踪已结束事务数和CPU资源消耗。

图5示出了在响应时间分布存储桶中的每事务的CPU消耗。也就是说，示出了包括28个存储桶的典型响应时间分布500，且额外示出了CPU消耗。对于当前实例，哪一个存储桶代表平均响应时间并不重要。唯一重要的是，分布左侧的存储桶(存储桶号1、2、3、......)代表所有短时间运行的事务，而分布右侧的存储桶(存储桶号......、26、27、28)代表长时间运行的事务。

图5中示例性地示出了存储桶中的结束或仍在运行的事务的平均CPU消耗，以便显示长时间运行的事务的资源消耗大大高于短时间运行的事务的资源消耗。该图示出了已结束事务的数目510和每事务的CPU消耗520。在此实施例中，使用CPU消耗来示出总资源消耗。但是，所述方法不限于CPU消耗。也可以使用其他类型的资源消耗。如图5所示，左侧第一存储桶1中的平均事务使用少于0.1％的CPU，而右侧最后一个存储桶28中的事务需要约14％的CPU。特别是在业务类周期具有高重要性和严格的目标来满足联机事务工作负荷的预期的情况下，此类变化可能损害计算机系统100的整体吞吐量。本发明的思想现在是标识此类变化并判定分割业务周期对系统吞吐量是否有益。也就是说，该思想是重新定义业务类周期，以便平均资源消耗在存储桶间是一致的。虽然大多数事务在第一存储桶(编号1、2、3、......)中结束，但是第一存储桶的资源消耗很好地指示了工作请求对计算机系统100中的其他工作的影响有多大。

如果要创建新的业务类周期，则根据本发明确定应将哪些事务移动到新的业务类周期中。

图6示出了由工作负荷管理器110执行的提出的算法的级数。在第一步骤300中，为每个业务类收集资源和响应时间数据。定期的数据收集和每个业务类周期的数据的汇总是所使用的算法的基础。数据收集周期在下文中被称为观测。由工作负荷管理器110执行数据收集和汇总。在收集数据之后，将更新每个业务类周期的响应时间/CPU消耗分布。

随后，以任意间隔定期检查所有业务类，确定是否应分割与该类关联的业务类周期或是否可再次删除关联的业务类周期(步骤301)。为此，将逐个检查业务类的所有业务类周期(步骤302)。在执行示出的工作流期间，将检查所有的业务类和所有的业务类周期。每个业务类的测试总是始于业务类的最后一个周期，即，具有最长时间运行的事务的业务类周期。

提出的算法结合了相反的或内务处理功能，其允许删除先前创建的业务类周期。因此，在接下来的步骤320，判定与已检查的业务类周期关联的工作单元的资源消耗是否变得太小，即，所述周期的资源消耗低于定义的目标值。下文中更详细地说明了标识低资源消耗的确切准则。没有针对业务类的第一业务类周期执行步骤320，因为第一周期由用户定义并因此从不被删除。对于业务类的第一业务类周期，在步骤320之后紧跟步骤310。

工作可以具有高活动性的时间周期和低活动性的时间周期。因此，只是分析业务类周期的当前资源消耗是不够的。因此，如果步骤320中的测试显示业务类周期不合适，则不会立即将业务类周期与之前的业务类周期相结合。相反，工作负荷管理器110对其中业务类周期的资源消耗低于定义目标值的连续观测(即，数据收集周期)数进行计数(步骤321)。该目标值可以由例如用户或自动由工作负荷管理器110通过装置设置，以确保在特定时间周期期间，可以存在具有低资源消耗的业务类周期。

在步骤321之后的接下来的步骤322中，判定观测数是否超过阈值。如果是，则在步骤323中删除已检查的业务类周期并将所收集的数据和已删除的业务类周期的所有工作单元与之前的业务类周期关联。

在步骤322中未满足准则的情况下，对当前业务类周期的检查结束且算法前进到步骤325。

在步骤325中，判定检查中的业务类周期是否是业务类的第一周期或在该循环中该业务类的周期是否改变(即，删除或创建)。如果满足第一准则，则在该循环中调查了已检查的业务类的所有周期。如果满足第二准则，则业务类的周期在该循环中已经更改且不检查已检查的业务类的其他周期，因为业务类周期的创建或删除可以对业务类的所有其他业务类周期具有重大影响，而系统需要时间来反映收集的数据中这些变化，以便能够决定其他变化是否合理。如果没有满足任一这些准则，则算法继续检查已检查的业务类的下一个业务类周期(步骤302)。如果满足这些准则之一，则算法对于已检查的业务类结束且在步骤330判定是否在该循环中检查了所有业务类。如果否，则算法继续在步骤301处理下一个业务类或如果已经处理了所有业务类，则算法对于该循环结束并继续步骤300的数据收集，直到执行下一测试为止。

如果未满足已检查的业务类的准则320，则在接下来的步骤310中判定所述业务类周期是否包含长时间运行和高CPU资源消耗的事务。

如果业务类周期包含长时间运行和高CPU资源消耗的事务，则所述业务类变为业务类周期分割的主题。在步骤310中，测试业务类周期是否满足分割的准则。下面更加详细地讨论了该准则。如果它满足该准则，则在步骤311中创建新的业务类周期。这也在下面详细说明。

如果业务类周期不包含长时间运行和高CPU资源消耗的事务，即，如果不满足步骤310的准则，则算法继续到当前已检查的业务类的下一个业务类周期或下一个业务类，这取决于步骤325和330的结果(参见上文)。

在步骤310中使用的周期分割准则确定了业务周期是否具有不一致的资源消耗。如果可以在业务类周期的响应时间存储桶中标识所谓的分割存储桶，则该业务类周期具有不一致的资源消耗。分割存储桶是具有最低存储桶号的存储桶，其中CPU消耗与所有之前的存储桶相比变得不一致。应用两个准则来判定此类分割存储桶是否存在：CPU消耗准则和最低分割存储桶准则。CPU消耗准则判定单独的响应时间存储桶是否具有不一致的CPU消耗。最低分割存储桶准则确保合理数量的事务将在业务周期(如果其被分割的话)中结束。最低分割存储桶准则确定具有最低存储桶号且允许成为分割存储桶的存储桶(称为最低分割存储桶)。如果已经根据最低分割存储桶准则确定了最低分割存储桶，则可以如下确定可能的分割存储桶。沿降低存储桶号的方向遍历存储桶。对于每个存储桶，验证CPU消耗准则。如果满足CPU消耗准则，则将该存储桶视为候选分割存储桶。存储桶的遍历在与两倍目标值关联的存储桶处停止。如果没有找到候选分割存储桶，则未满足周期分割准则并执行步骤325。否则，满足周期分割准则，并且分割存储桶等于所找到的最后一个候选分割存储桶(如果其存储桶号大于最低分割存储桶号)，或者分割存储桶等于最低分割存储桶(如果其存储桶号小于或等于所找到的最后一个候选分割存储桶)。

可以定义不同的CPU消耗准则和最低分割存储桶准则。但是，目标始终是以这样的方式标识分割存储桶：在该存储桶处的业务周期的分割导致分割业务周期的存储桶间的一致平均资源消耗。接下来，给出此类准则的一些实例。这些实例准则依赖于每存储桶的累计CPU消耗和每存储桶的结束事务的总数。

图7示出了图700，其示出了单个业务类周期的第1到第28号存储桶中的累计CPU消耗710和结束的事务总数720。图7中的垂直线701代表确定的分割存储桶。水平线702代表最低分割存储桶准则。箭头703和704示出了其中执行数据分析的方向。

可以例如通过以下方式来确定CPU消耗准则：如果调查的存储桶与随后的存储桶之间的资源消耗的增加以及之前的存储桶与调查的存储桶之间的资源消耗增加超过了装置定义的比例阈值(例如，3)，则调查的存储桶是候选分割存储桶。使用该方法，图7中最后一个候选分割存储桶将是第26个存储桶。

备选地，可以例如通过以下方式确定CPU消耗准则：将前N个存储桶(例如，N＝4)的累计资源消耗视为一致资源消耗。如果调查的存储桶超过了一致资源消耗阈值因数(例如，因数2)，则它是候选分割存储桶。使用该方法，图7中最后一个候选分割存储桶将是第15个存储桶。

可以例如通过以下方式确定最低分割存储桶准则：最低分割存储桶是特定装置定义的百分之P(例如，P＝90％)的事务已结束的存储桶。P＝90％时，最低分割存储桶将是图7中的第10个存储桶。

备选地，由固定装置定义的存储桶号(例如，第20个存储桶)来标识最低分割存储桶。

标识的分割存储桶用于在步骤311中定义分割周期的业务类周期持续时间和创建新的业务类周期。也就是说，如果几乎所有第27和28个存储桶的事务都将与新的业务类周期关联，则第26个存储桶的平均资源消耗用作切换准则，即，用作业务类周期切换条件。为了实现分割存储桶之后的存储桶的所有事务都与新的业务类周期关联，将持续时间分配给分割业务类周期，其将资源消耗限制为不大于在分割存储桶中结束的事务的平均资源消耗。如果没有事务在分割存储桶中结束，即，如果该存储桶为空，则将分割存储桶的资源消耗从分割存储桶之前的最后一个非空存储桶内插到分隔存储桶之后的第一个非空存储桶。在该持续时间中，当事务由于其他原因在系统中延迟但未在该时间使用资源时，仍将有少量在第一业务类周期的最后存储桶中结束的事务。此外，一些在分割存储桶之前的存储桶(即，在图7中第27个存储桶之前)中结束的事务将可能切换到新的业务类周期。这些事务是短时间运行但具有更多资源消耗的事务的实例。

对于新创建的业务类周期的目标，将应用直接的方法。总体目标是使长时间运行的事务对系统中的其他工作的影响最小化。考虑对于在相同重要性和稍低重要性级别的工作产生最大影响，最重要的参数是新周期的重要性。为了确定新业务类周期的重要性，由工作负荷管理器测量其他工作在相同和较低重要性级别处的资源消耗。根据为新的业务类周期预测的资源量，工作负荷管理器110通过将新的业务类周期移动到较低的重要性级别，来帮助为其使用基本相同的资源量的其他工作。将此类工作移动到较低的重要性级别，直到其他工作(表现相同或接近相同的资源消耗)具备对资源的相同或更好的访问。

作为第二准则，观测了由上述机制从其他业务类创建的业务类周期，并且工作负荷管理器110不会将新的业务类周期移动到比同样级别的其他业务类周期更低的重要性级别，所述其他业务类周期从与原始业务类周期位于相同重要性级别的其他业务类的工作来创建。

如果分割业务类周期具有基于响应时间的目标，则将新的业务类周期与基于响应时间的目标关联，所述目标设置为等于与分割存储桶关联的响应时间。如果分割业务类周期具有面向吞吐量的目标，则将新的业务类周期与相同的面向吞吐量的目标关联，将所述目标降低装置定义的因数。

可以按照下文判定周期的业务消耗是否低于目标(步骤320)：如果第一业务类周期中存在活动且如果结束的事务数或业务类周期的累计CPU消耗落到装置定义的目标值以下，则业务类周期满足准则320并考虑删除。如果仅在第一业务类周期中存在活动时删除业务类周期，则可以避免在系统处于低争用状态或无争用状态时删除业务类周期。如果删除的业务类周期之后跟随其他业务类周期，则将之前的业务类周期的持续时间设置为删除的业务类周期的持续时间。如果不存在后续的业务类周期，则删除之前的业务类周期的持续时间。

在更复杂的方法中，使用了组合的响应时间存储桶分布，其由工作负荷管理器110从检查的业务类周期和之前的业务类周期的响应时间存储桶分布来生成。

对于组合的响应时间分布，应用了标识分割存储桶(参见上文)的方法。如果不能确定分割存储桶，则考虑删除业务类周期。前提是，如简单的方法那样，在第一业务类周期中存在活动。对于以上简单的方法，如所描述的那样更新之前的业务类周期的持续时间。

标号

1    第一组时间存储桶

2    第二组时间存储桶

10   时间存储桶

20   时间存储桶

40   存储桶

41   第一个存储桶

42   第八个存储桶

43   范围

44   范围

45   最后一个存储桶

100  计算机系统

101  操作系统

110  工作负荷管理器

111  业务定义

120  业务类表

121  业务类

122  业务类周期

123  业务目标

124  响应时间

125  执行速度

126  重要性级别

127  持续时间

128  样本和管理数据

130  目标管理设备

140  操作系统资源

141  CPU资源

150  操作系统用户

151  子系统

152  工作单元

160  数据采样器

200  应用

201  线程

211  内部表示

212  状态教据

223  状态数据存储桶

224  响应时间分布

300-330  方法步骤

400  分布

500  时间分布

510  结束的事务数

520  每事务的CPU消耗

700  图

701  确定的分割存储桶准则

702  最低分割存储桶准则

703  数据分析的方向

704  数据分析的方向

710  累计CPU消耗

720  已结束事务的总数

Claims (6)

1.一种计算机系统(100)中的工作负荷管理的方法，

其中将工作单元(152)组织成业务类(121)，向所述类提供特定量的系统资源(140)，以及

其中将多个业务类周期(122)与每个业务类(121)关联，

其特征在于：

确定至少一个当前业务类周期(122)内的工作负荷行为，以及

根据所述确定的工作负荷行为来自动调整可用业务类周期(122)的数量。

2.如权利要求1中所述的方法，其中根据所述确定的工作负荷行为来自动调整业务类周期(122)的特性。

3.如权利要求1中所述的方法，其中所述确定工作负荷行为的步骤包括确定事务完成时间和确定事务的资源消耗。

4.如权利要求1中所述的方法，其中所述调整可用业务类周期(122)的数量的步骤包括自动创建其他业务类周期(122)。

5.如权利要求1中所述的方法，其中所述调整可用业务类周期(122)的数量的步骤包括自动删除当前的业务类周期(122)。

6.一种用于计算机系统(100)的工作负荷管理器(110)，

其中将工作单元(152)组织成业务类(121)，向所述类提供特定量的系统资源(140)，以及

其中将多个业务类周期(122)与每个业务类(121)关联，

其特征在于，所述工作负荷管理器包括：

用于确定当前业务类周期(122)内的工作负荷行为的装置，以及

用于根据所述确定的工作负荷行为来自动调整可用业务类周期(122)的数量的装置。

Images