CN115803716A - 用于流处理应用程序的自动调整大小 - Google Patents

用于流处理应用程序的自动调整大小 Download PDF

Info

Publication number
CN115803716A
CN115803716A CN202180046873.4A CN202180046873A CN115803716A CN 115803716 A CN115803716 A CN 115803716A CN 202180046873 A CN202180046873 A CN 202180046873A CN 115803716 A CN115803716 A CN 115803716A
Authority
CN
China
Prior art keywords
policy
application
data
computer resource
policies
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202180046873.4A
Other languages
English (en)
Inventor
A·沙瓦纳
B·库马拉苏布拉马尼安
P·马赫什瓦里
R·P·辛格
S·谢蒂
K·帕拉马西瓦姆
谢凡
P·乔克拉
S·贾因
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Microsoft Technology Licensing LLC
Original Assignee
Microsoft Technology Licensing LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Microsoft Technology Licensing LLC filed Critical Microsoft Technology Licensing LLC
Publication of CN115803716A publication Critical patent/CN115803716A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/5055—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering software capabilities, i.e. software resources associated or available to the machine
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G06F9/5072—Grid computing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
    • G06F9/5016—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals the resource being the memory
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/505—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the load
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/50—Indexing scheme relating to G06F9/50
    • G06F2209/504—Resource capping
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Mathematical Physics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Artificial Intelligence (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Data Mining & Analysis (AREA)
  • Evolutionary Computation (AREA)
  • Medical Informatics (AREA)
  • Computing Systems (AREA)

Abstract

提供了自动重调应用程序大小的技术。在一种技术中，存储指示多个策略的顺序的策略数据。这些策略包括(1)对应于第一计算机资源和第一重调大小动作的第一策略，以及(2)优先级低于第一策略并且对应于第二重调大小动作和第二计算机资源的第二策略。从在云环境中执行的至少一个应用程序接收资源利用数据。基于顺序，识别第一策略。基于资源利用数据，关于应用程序确定是否满足与第一策略相关联的标准。如果满足，则关于应用程序执行第一重调大小操作；否则，基于计算机资源利用数据，确定与第二策略相关联的标准是否得到满足。

Description

用于流处理应用程序的自动调整大小
技术领域
本公开总体上涉及流处理应用程序，并且更具体地涉及在云环境中自动调整流处理应用程序的大小。
背景技术
当存在可用于程序的足够的计算资源(例如存储器和CPU)时，软件程序(或“应用程序”)最高效地执行。为应用程序供应计算机资源的一种方法是允许应用程序开发者指定应用程序在执行期间将使用的每种资源类型的数量。这种方法可能会导致过度供应或供应不足。供应不足的应用程序将执行不佳，表现为吞吐量降低和/或延迟增加，或者处理停顿导致高尾延迟。例如，如果为应用程序供应相对较少的存储器，则该应用程序可能会不断被中断以等待数据从存储器中换出，以便为存储新获取的数据腾出空间。
关于过度供应，虽然过度供应的应用程序可以最佳地运行，但是支持该应用程序的成本增加并且该应用程序的维护变得昂贵。此外，过度供应一个应用程序可能会导致其他应用程序没有足够的计算机资源来最佳地执行。
为云应用程序(或在“云”中运行或执行的应用程序)供应计算机资源的一种方法是实施监测多个应用程序的性能并基于性能作出供应决策的供应服务。(在现代云环境中，在单个云中运行的不同应用程序的数量可以有数百或数千。)这种针对应用程序而动态供应计算机资源被称为对应用程序“重调大小”(resize)。因此，“重调大小”确定或决策导致重调大小动作或无动作。
存在实现供应服务的多种方法，每种方法都在一个或多个方面存在缺陷。例如，一种方法侧重于扩展并行度以满足应用程序的延迟和吞吐量目标，同时将应用程序建模为运算符的有向无环图(DAG)。然而，生产应用程序已经以多种方式偏离该模型，导致它们具有异构的性能特征。例如，一些应用程序使用远程服务、维护状态、使用用户定义的函数和外部框架，并且组合不同的功能。因此，仅调整应用程序的并行度而不考虑其他大小调整参数、服务依赖性和环境变量通常会导致供应不足(或“规模不足”)的应用程序，从而导致吞吐量下降、延迟增加和处理停顿。
另一种方法实施一个或多个复杂的“爬山”优化技术以确定接下来执行什么重调大小动作，如果有的话。然而，这样的技术是随机的，因此，一次针对云应用程序的重调大小动作可能与另一次针对该云应用程序的重调大小动作非常不同，即使两次期间云应用程序的状态可能相同。此外，执行取证分析以确定应用程序在此类环境中崩溃或性能下降的原因非常耗时且具有挑战性。
另一种方法涉及自动尝试许多不同的重调大小动作直到性能问题消失。如果在一个或多个重调大小操作的情况下仍然存在性能问题，则此类方法还涉及发出许多撤消动作。但是，实施单个重调大小动作(并撤消重调大小动作)可能需要花费大量时间才能完成。因此，这种方法会通过发出许多不必要的重调大小动作和相对应的撤消动作而导致计算资源的浪费。
本节中描述的方法是可以采用的方法，但不一定是先前已经设想或采用的方法。因此，除非另有说明，否则不应假定本节中描述的任何方法仅仅因为它们包含在本节中就符合现有技术的条件。
附图说明
附图中：
图1是描绘在一个实施例中用于在云环境中重调应用程序大小的示例云系统的框图；
图2A是描绘在一个实施例中用于在云环境中重调应用程序大小的示例过程的流程图；
图2B是描绘在一个实施例中用于在确定要考虑哪些策略时将由应用程序使用的远程服务的性能考虑在内的示例过程270的流程图；
图3是说明可在其上实施本发明的实施例的计算机系统的框图。
具体实施方式
在下面的描述中，出于解释的目的，阐述了许多具体细节以提供对本发明的透彻理解。然而，很明显，可以在没有这些具体细节的情况下实施本发明。在其他情况下，公知的结构和设备以框图形式示出以避免不必要地模糊本发明。
总体概述
提供了一种用于自动重调应用程序大小的系统和方法。在一种技术中，定义并实施了有序策略集，每个策略对应于不同的计算机资源。其中一个策略对应于存储器，而该策略集中的后续策略对应于中央处理单元(CPU)，该策略规定有多少CPU可以专用于执行应用程序。因此，与CPU相关的重调大小决策仅在不针对应用程序而对存储器重调大小的决策之后发生。在相关技术中，其中一个策略对应于CPU，而后续策略对应于并行度(parallelism)，即指派给应用程序的线程数或核心数。因此，与应用程序的并行度有关的重调大小决策仅在不针对应用程序重调CPU大小的决策之后发生。
在相关实施例中，使用应用程序检查点测量应用程序积压的变化，并且该变化用于确定是否重调应用程序的并行度特征的大小，例如增加线程的数量或创建应用程序的另一实例。
在相关实施例中，有序策略集包括用于按比例缩小计算机资源的供应的策略。例如，缩小存储器先于缩小CPU，缩小CPU先于缩小并行度。
实施例通过自动重调应用程序的大小来改进计算机相关技术，从而避免通常在应用程序开发者指定供应参数时导致的计算机资源供应不足和过度供应。此外，实施例实现了可解释的和确定性的决策，并避免了在其他大小重调解决方案中常见的持续撤消动作。
流处理
一些类型的应用程序由于其任务的性质而难以供应。这种应用程序的一个示例被称为流处理应用程序。“流处理”是对“动态数据(data in motion)”的处理，换句话说，在产生或接收数据时直接处理数据。许多现代数据以连续流的形式产生：传感器事件、网站上的用户活动等。此类数据随着时间被创建为一系列事件。
在流处理之前，该数据通常存储在数据库、文件系统或其他形式的大容量存储中。应用程序将根据需要查询数据或对数据进行计算。流处理扭转了这种模式：应用程序逻辑、分析和查询持续存在，并且数据持续流经它们。在从数据流接收到事件后，流处理应用程序通过触发动作、更新聚合或其他统计信息或“记住”该事件以供将来参考来对该事件做出反应。流处理应用程序还可以联合处理多个数据流，并且对数据流的每次计算都可以产生其他数据流。
尽管本文描述的示例涉及流处理应用程序，但是实施例适用于非流处理应用程序和工作负载，例如批处理或“在线”网络服务工作负载。
示例云服务
图1是描绘在一个实施例中用于在云环境中重调应用程序大小的示例云系统100的框图。云系统100包括集群管理器110、应用程序容器112-116、存储118和重调大小控制器120。虽然只描绘了单个集群管理器110，但是云系统100可以包括多个集群管理器，每个管理不同的计算机器集群。此外，虽然仅描述了两个非主应用程序容器，但是云系统100可以包括许多非主应用程序容器和多个应用程序主容器。
云系统100是托管多个(云)应用程序并运行多个云服务的计算平台。云服务是经由因特网从云提供商的服务器按需提供给用户的服务，而不是从公司自己的本地服务器提供的服务。云服务被设计为提供对应用程序、资源和服务的可扩展访问，并且通常由云服务提供商完全管理。云服务的示例包括在线数据存储和备份解决方案、基于Web的电子邮件服务、托管办公套件和文档协作服务、数据库处理、受管技术支持服务等。
云系统100由云服务提供商提供，其可以是私有的(在这种情况下云系统100仅托管和运行来自单个组织的应用程序)或公共的(在这种情况下云系统100托管和运行来自不同实体或组织的应用程序)。公共云服务提供商的示例包括Microsoft Azure、GoogleCloud、Amazon Web Services(AWS)和IBM Cloud。
云系统100托管的(云)应用程序的示例包括生成通知的应用程序、允许用户以数字方式编辑实体简档(例如，用户简档或组织简档)的应用程序、检测重复、欺诈或滥用的应用程序、计算用户选择率的应用程序、监控信任的应用程序以及执行电子账单任务(或生成用于电子账单任务的数据)的应用程序。
应用程序可以在容器的上下文中运行。容器是标准的软件单元，它将应用程序的代码(例如，应用程序二进制文件)及其所有依赖项打包在一起，以便应用程序可以快速可靠地从一个计算环境运行到另一个计算环境。容器可用于基于Linux和Windows的应用程序两者。无论基础设施如何，容器化软件的运行方式都是一样的。
在实施例中，由云系统100托管的单个应用程序的多个实例同时执行。应用程序的每个实例都在容器的上下文中执行。因此，多个应用程序容器可以对应于同一应用程序，执行相同的逻辑。
非主应用程序容器(例如应用程序容器112)是应用程序的主要处理单元。主应用程序容器(例如主应用程序容器116)充当非主应用程序容器的协调器。每个非主应用程序容器周期性地向主应用程序容器发送指示非主应用程序容器仍在运行的心跳(或保活)消息。如果主应用程序容器没有从非主应用程序容器接收到心跳消息，则主应用程序容器指示集群管理器110实例化新的非主应用程序容器来代替“静默的”非主应用程序容器。
非主应用程序容器112-114中的每个生成输出，输出被存储在存储118中。存储118可以是持久性存储或非持久性存储。应用程序容器112-114生成的输出的示例包括处理来自事件/消息队列的事件或消息的结果、与一个或多个其他(“下游”)应用程序订阅的主题相关的新事件、到数据库的写入、到一个或多个消息队列的消息、云存储服务、日志记录服务、通知服务(例如，向用户发送电子邮件、移动通知等)和其他网络服务。
除了启动非主应用程序容器之外，集群管理器110还执行簿记任务，例如跟踪每台机器上的容器数量、哪些机器具有额外容量以及哪些机器具有低容量。基于云系统100中多台机器中每台机器的容量，集群管理器110将特定应用程序容器指派给云系统100中的特定机器。每个应用程序容器映射到一组资源(例如，CPU、存储器等)并且集群管理器110对不同机器上的这些资源分配执行簿记。将应用程序容器指派给机器可以涉及在云系统100中的机器上启动新的应用程序容器或将现有应用程序容器移动到云系统100中的另一台机器。
集群管理器110还从主应用程序容器接收资源分配指令，例如将10GB存储器分配给一个应用程序容器的指令以及将50％的CPU分配给六个其他应用程序容器中的每个的另一指令。响应于从主应用程序容器接收到资源分配指令，集群管理器110将指定的资源量分配给指定的应用程序容器。
重调大小控制器
重调大小控制器120包括数据收集器122、策略引擎124、动作日志126和重调大小器128。数据收集器122、策略引擎124和重调大小器128中的每个都以软件、硬件或软件和硬件的任何组合来实现。重调大小控制器120的这些元素中的一些可以在单个程序中实现或者可以分布在多个程序中。无论重调大小控制器120执行的任务的分布以及实现这些任务的程序的数量如何，重调大小控制器120都可以在云系统100的一个或多个机器上执行。
数据收集器122从一个或多个数据源(例如存储118和非主应用程序容器112和114)接收计算机资源利用数据。计算机资源利用数据的示例包括应用程序容器当前使用的存储器量、应用程序容器正在使用的CPU的百分比、已针对应用程序接收的事件或消息的数量、以及应用程序容器最近已经处理的特定事件或消息。
数据收集器122可以基于它已经从一个或多个数据源接收到的资源利用数据来计算额外的计算机资源利用数据。例如，如下文更详细描述的，数据收集器122基于输入流的当前“最后”偏移量和应用程序在该输入流上的检查点偏移量来计算积压。数据收集器122计算的数据的另一个示例是在每个应用程序的基础上的聚合利用率，例如通过计算来自应用程序的所有容器的数据点的运行时最大值(对于给定的时间戳)。
为了在每个应用程序的基础上聚合来自多个应用程序容器的利用数据，数据收集器122从应用程序容器112-114接收利用数据并且将利用数据与相应的应用程序容器相关联地存储，例如，使用唯一标识每个应用程序容器的元数据。数据收集器122将经组织的数据存储在临时存储(未描绘)中。
数据收集器122可以连续执行，使得数据收集器122有规律地(例如，每隔几秒或每分钟)从一个或多个数据源取回(例如，请求)数据。附加地或替代地，一个或多个数据源向数据收集器122发送(或“推送”)数据。例如，数据源充当与特定主题有关的数据的发布者并且数据收集器122充当与特定主题有关的数据的订阅者。数据收集器122被称为“收听”特定主题。中央发布-订阅服务(未描绘)将发布的数据路由到该数据的订阅者。流处理软件平台的示例是Apache Kafka。在此示例中，应用程序容器112-114向中央发布-订阅服务发送数据信标(例如，每分钟)，并且数据收集器122使用这些数据信标。
策略引擎124访问经组织的数据并确定是否应对与特定计算机资源相关的特定应用实施重调大小动作。这种确定基于包括基于优先级排序的策略集的策略数据。该策略集中的每个策略对应于一个计算机资源，指示一个动作(增加(或放大)或减少(或缩小)相应的计算机资源)，以及用于确定是否发起该动作的一个或多个度量。计算机资源的示例包括堆、存储器、CPU(中央处理单元)、并行度、RDMA(远程数据存储器访问)和GPU(图形处理单元)。
在一个实施例中，数据收集器122在每个应用程序的基础上聚合容器级利用数据，并且策略引擎124在每个应用程序的基础上基于经聚合的利用数据做出决定。这可以是因为应用程序的一些容器比应用程序的其他容器占用更多资源的问题相对较少。然而，在另一实施例中，策略引擎124被扩展以在每个容器的基础上使用簿记并且在每个容器的基础上做出决定。
策略启动标准
每个策略与一个或多个启动标准相关联，如果满足这些启动标准，将导致触发或启动对应于该策略的动作。不同策略的启动标准可以由重调大小控制器120的用户或管理员指定。
取决于计算机资源的类型，一个或多个启动标准可以从一个策略到另一个策略不同。不同的启动标准涉及不同的度量。例如，对于存储器，启动标准可以是已分配给应用程序的存储器的使用率达到95％。因此，如果应用程序当前正在使用已分配给该应用程序的存储器的95％以上，则满足启动标准并触发相应的动作。作为另一示例，对于CPU，启动标准可以是已分配给应用程序的CPU的使用率达到90％。因此，如果应用程序当前正在使用已分配给该应用程序的CPU的90％以上，则满足启动标准并触发相应的动作。作为另一示例，对于并行度，启动标准可以是在特定时间段内积压增加大于5％。因此，如果与应用程序相关联的积压相对于前一个时间点增加超过5％，则满足启动标准并触发相应的动作。
特定应用程序容器可以在托管一个或多个其他应用程序容器的计算设备(例如，服务器)上执行。因此，特定应用程序容器与其他应用程序容器共享计算设备的存储器资源。例如，三个应用程序容器中的每个可以已经分配了计算设备总存储器的33％。因此，95％的存储器使用率阈值可以转化为计算设备总存储器的大约31％。
在一个实施例中，策略与多个启动标准相关联。例如，对于与增加堆存储器相关的策略，多个启动标准可以基于由应用程序当前使用的堆的数量、在一段时间内执行垃圾收集的(例如，平均或中值)时间，以及在该时间段期间调用垃圾收集的次数。
在确定是否执行与策略相关联的动作时，可以将多个启动标准中的一个或多个考虑在内。对于具有多个启动标准的一些策略，只需要满足启动标准中的一个就可以触发相应的动作，而对于其他具有多个启动标准的策略，则需要满足所有(或多个)启动标准才能触发相应的动作。以堆上下文中的前一种场景为例，如果应用程序在一段时间内调用垃圾收集的次数大于N，则触发相应的动作，即使由应用程序使用的堆数量相对较低，因此不满足与所使用的堆的数量相对应的启动标准。以堆上下文中的后一种场景为例，为了触发应用程序的动作，则由应用程序使用的堆量必须大于分配给应用程序的某个百分比，调用垃圾收集的次数大于N，并且垃圾收集在每次调用上花费的平均时间大于T(例如，以毫秒为单位)。
有序策略集
下表列出了策略引擎124应用于不同应用程序或应用程序容器的策略。
Figure BDA0004029245320000051
表A
在表A的示例中，“堆”和“存储器”是两种不同类型的计算机资源。其他实施例可以不具有针对不同类型存储器的单独策略。“堆”是一种特定类型的存储器，并且“存储器”可以仅指非堆存储器，也可以指堆存储器和其他类型的存储器，如栈存储器、缓冲存储器等。堆存储器是可以随机访问分配的存储器。与以非常明确的顺序分配和释放存储器的栈存储器不同，在堆上分配的各个数据元素通常以彼此异步的方式释放。虽然此示例包括多种类型的存储器，但其他示例可以不区分不同类型的存储器。
在表A的示例中，在逻辑资源分配(P4)之前分析物理资源分配(P1-P3)。物理资源分配(例如，堆、存储器、CPU、GPU、RDMA功能和NVRAM)可被视为环境的属性，而逻辑资源分配(即并行度)可被视为应用程序的属性。(逻辑资源分配的另一个示例包括应用程序可以正在使用的远程服务的请求速率限制，例如云存储、通知服务或其他网络服务。)一旦确定环境的属性不是问题，则检查应用程序的属性。
按优先顺序处理策略
在一个实施例中，策略引擎124在考虑策略集合中的任何其他策略之前首先考虑最高优先级策略(例如，表A中的P1)。如果策略引擎124确定不满足最高优先级策略的一个或多个启动标准(或者换句话说，不应执行与最高优先级策略相关联的动作)，则策略引擎124仅考虑第二最高优先级策略(例如，表A中的P2)。因此，在考虑最低优先级策略(例如，表A中的P8)之前，策略引擎124首先确定不应执行与其他策略相关联的任何动作。通过这种方式，重调大小的决策是可解释的和确定性的，而不是随机做出的。
在相关实施例中，如果策略引擎124确定应该执行特定策略的动作，则策略引擎124在考虑优先级比特定策略更高的任何策略和特定的策略本身之前，不考虑在优先级顺序上在该特定策略之后的任何策略。因此，策略引擎124在未来某个时间考虑的下一个策略是最高优先级策略(例如，表A中的P1)。
图2A是描绘在一个实施例中用于在云系统中重调应用程序大小的示例过程200的流程图。过程200可以由重调大小控制器120的一个或多个组件来实现。
在框210，存储指示多个策略的顺序的策略数据。策略数据可由策略引擎124访问。可以由云系统100的用户或管理员指定启动标准和规定应用程序的新资源分配的任何重调大小动作规则。
在相关实施例中，可以针对不同的应用程序集指定不同的策略数据集。例如，针对一个应用程序集的计算机资源分配可以由一个策略数据集规定，而针对另一应用程序集的计算机资源分配可以由另一策略数据集规定。
在框220，接收关于在云系统100中执行的应用程序的计算机资源利用数据。计算机资源利用数据可以包括(1)指示应用程序当前正在使用的特定计算机资源的利用数据和(2)指示应用程序未决的事件或消息的数量的积压数据，这将在下面更详细地描述。框220可以由数据收集器122执行并且可以在过程200的后续块被执行的同时连续地执行。
在框230，基于策略数据中指示的顺序，识别特定策略。特定策略对应于特定计算机资源。如果这是第一次执行框230，则所识别的策略是策略数据中指示的最高优先级策略。给定表A中的示例，识别了策略P1。
在框240，基于计算机资源利用数据，关于应用程序确定是否满足与所识别的策略相关联的一个或多个启动标准。例如，如果所识别的策略的计算机资源是堆，则启动标准可以是应用程序当前的堆利用率是否大于分配给该应用程序的当前堆的90％，以及平均垃圾收集时间是否大于十毫秒。如果满足一个或多个启动标准，则过程200进行到框250。否则，过程200进行到框260。
在框250，使得针对应用程序和特定计算机资源执行重调大小动作。例如，重调大小器128向主应用程序容器116发送重调特定应用程序或应用程序容器的大小的指令。该指令指示计算机资源(例如，堆存储器)、特定应用程序或一个或多个应用程序容器，以及新的分配量(例如，10GB)。此后，策略引擎124不分析或不考虑第一策略的后续策略，直到策略引擎124确定不满足与第一策略相关联的一个或多个第一启动标准为止。
如果执行框250，则过程200返回到框220，在框220接收额外的计算机资源利用数据。框230的下一次迭代将涉及从策略数据中识别最高优先级策略。在执行框230的下一次迭代之前可以经过一定时间段。该时间段是重调大小动作可以生效的时间。在该时间段之后，将确定重调大小动作是否解决了使得满足框240的最近迭代中的一个或多个启动标准的利用不足(或过度利用)的问题。
在框260，确定策略数据中是否指示了更多策略。如果是，则过程200返回框230，其中识别另一策略，即在框230中最近识别的策略之后的策略。例如，策略引擎124在框230的第二次迭代中识别来自表A的策略P2。如果过程200进行到框260，则至少在过程200的这个迭代期间不使得执行与框230中最近识别的策略相关联的重调大小动作。
如果框260中的确定是否定的，则过程200可以等待返回框220，在框220中获得额外的计算机资源利用数据。可以在将来的另一时间自动调用框220。例如，在考虑存储的策略数据中的所有策略并确定不执行重调大小动作之后，策略引擎124可以等待几秒或一分钟以允许取回额外的计算机资源利用数据(在框220)并且最高优先级策略被再次识别(在框230)。
优先考虑计算机资源的具体示例
即使应用程序有足够的总存储器，堆存储器量不足也会导致性能问题。例如，堆存储器越小，调用垃圾收集的频率就越高，每个垃圾收集实例完成所需的时间也就越长。用于垃圾收集的CPU资源越多，可用于其他处理的CPU资源就越少。因此，在一个实施例中，与堆有关的策略优先于与存储器或总存储器有关的策略。此外，在相关实施例中，与存储器相关的策略优先于与CPU相关的策略。因此，仅在确定不应执行与与存储器相关的策略相关联的动作之后才考虑与CPU相关的策略。
在一个实施例中，与CPU相关的策略优先于与并行度相关的策略。因此，仅在确定不应执行与CPU相关的策略相关联的动作之后才考虑与并行度相关的策略。如果策略引擎124在CPU动作之前考虑并行度动作，则策略引擎124将做出次优重调大小动作的可能性相对较高。例如，增加并行度的重调大小动作可能无法解决影响CPU使用率的潜在性能问题。因此，增加并行度会浪费时间和计算资源。
对计算机资源重调大小
一旦策略引擎124确定应用程序的计算机资源(例如，存储器、并行度)要重调大小(增加或减少)，策略引擎124(或重调大小控制器120的另一组件)确定应用程序的新资源分配。可以以一种或多种方式执行这种确定。
在一个实施例中，重调大小控制器120实施关于要增加(或减少)多少应用程序针对特定计算机资源的当前分配的一个或多个规则。作为具体示例，一个规则可以是将应用程序的当前存储器分配加倍。因此，如果当前存储器分配为10GB，则新的存储器分配将为20GB。作为相关示例，如果在最后两分钟内对应用程序执行了肯定的重调大小动作，则另一规则可以是将应用程序的当前存储器分配增加四倍。在应用程序的到达率或对应用程序的请求数量显著增加的情况下，这种存储器分配速率的增加避免了增量重调大小动作。
用于对应用程序的并行度进行重调大小的规则的示例是将分配给应用程序的当前线程数增加50％。当前线程数可以通过将容器数乘以容器的线程数来确定。如果新线程分配违反每个容器线程限制(例如，每个容器16个线程)，则实例化并执行应用程序的一个或多个新容器，其中应用程序的新容器总数和应用程序的新线程数不违反每个容器线程限制。如果确定一个或多个新的应用程序容器应该被实例化，则这些新的应用程序容器的其他类型的计算机资源(例如，存储器和CPU)的分配量可以保持与一个或多个现有应用程序容器的资源分配量相同，或者可能是最小分配量，例如1GB存储器和10％的CPU。
在一个实施例中，每个重调大小动作都记录在日志126中。日志126可以在将来的重调大小决策中使用。例如，如果应用程序接收到上次策略P2考虑时的2倍的存储器分配增加，并且策略引擎124确定当前存储器分配的利用率为100％，则策略引擎124可以确定存储器分配应增加4倍。
在一个实施例中，重调大小器128实现重调大小动作并将具体的重调大小指令传送到主应用程序容器116。重调大小器128的目的是实施云系统限制，使得应用程序不消耗云系统100的机器集群或整个云系统100中的特定类型的所有计算机资源。如果策略引擎124或数据收集器122的逻辑中存在错误，则此类错误可能导致做出不切实际的重调大小决策。重调大小器128可以防止这种不切实际的重调大小决策压倒(overwhelm)云系统100。
因此，给定应用程序的“全局”重调大小量(例如，新的存储器分配或新的线程计数)，重调大小器128基于某些约束确定每个应用程序容器的新资源配置。确保重调大小决策不会压倒云系统100或其部分的约束示例包括每机器限制、每容器限制和每应用程序限制。每机器限制的示例包括由该机器上的容器引起的网络流量的量、分摊到机器上的核心数量上的机器上的线程总数。
每容器限制的示例包括对可以分配给每个容器的存储器量的限制、对可以分配给每个容器的CPU量的限制、以及对可以分配给每个容器的线程数的限制。
每应用程序限制的示例包括对可以分配给应用程序的存储器量的限制和对可以分配给应用程序的CPU量的限制，以及对可以分配给应用程序的线程数的限制。不同的应用程序可以具有不同的应用程序限制。例如，一些应用程序的存储器限制可以高于其他应用程序的存储器限制。每种类型的限制(无论是机器、容器还是应用程序)都可以是默认值和/或可配置的。
在相关实施例中，如果达到限制，则重调大小器128生成错误消息并使错误消息被持久存储并传输到一个或多个目的地，例如以在计算机资源仪表板上呈现的文本消息、电子邮件消息或警报的形式，其以一个或多个粒度级别(例如机器集群级别、应用程序级别、容器级别或个体机器级别)呈现云系统100的当前资源使用统计信息。
对计算机资源重调大小和机器学习
在相关实施例中，重调大小控制器120使用机器学习的模型来确定应用程序针对特定计算机资源的新分配。基于在云系统100中执行的应用程序的过去的性能，可以已经使用一种或多种机器学习技术来训练机器学习的模型。
机器学习是研究和构建可以从数据中学习并对数据做出预测的算法。此类算法通过从输入构建模型以便做出数据驱动的预测或决策来进行操作。因此，机器学习技术用于生成统计模型，该统计模型基于与用户和区域相关联的属性值的历史进行训练。基于本文描述的多个属性训练统计模型。在机器学习的术语中，这些属性被称为“特征”。要生成和训练统计预测模型，需要指定一组特征并识别一组训练数据。
实施例不限于用于生成机器学习的模型的任何特定机器学习技术。示例机器学习技术包括线性回归、逻辑回归、随机森林、朴素贝叶斯和支持向量机(SVM)。机器学习的模型相对于基于规则的模型的优势包括机器学习预测模型捕获特征之间非线性相关性的能力，以及在确定不同特征权重时减少偏差的能力。
机器学习的模型可以输出不同类型的数据或值，这取决于输入特征和训练数据。例如，对于每个过去的重调大小动作，训练数据可以包括多个特征值，每个特征值对应于云系统性能的不同特征。为了生成训练数据，在每次过去重调大小期间(或紧接之前)分析有关应用程序性能的信息，以计算不同的特征值。
最初，考虑用于训练的特征的数量可能是重要的。在训练和验证模型后，可以确定特征的子集对最终输出几乎没有相关性或影响。换句话说，这些特征的预测能力很低。因此，此类特征的机器学习权重可能相对较小，例如0.01或-0.001。相反，具有显著预测能力的特征的权重可能具有0.2或更高的绝对值。可以从训练数据中去除预测能力很小的特征。去除此类特征可以加快训练未来模型和进行重调大小动作的过程。
应用程序性能可以反映在数据收集器122或云系统100的另一个组件收集的数据中。机器学习的模型的输出可以因实现方式而异，并且根据机器学习的模型正在计算新的资源分配所针对的计算机资源而变化，这在下面有更详细的描述。
机器学习的模型的特征示例包括：特定类型的应用程序(例如，映射、过滤器、连接)的操作数量、应用程序的有状态操作的数量、相对于当前存储器分配的当前存储器使用(例如95％)、当前存储器分配的日志、应用程序的未决请求数量、自上一个时间点以来未决请求数量的相对变化、应用程序自上一个时间点以来已处理的请求数的相对变化。上一个时间点的示例包括应用程序发生重调大小事件的最后时间和考虑策略的启动标准的最后时间。
“有状态(stateful)”操作是需要应用程序维持状态以便完成操作的操作。有状态操作比无状态(stateless)操作更可能是资源密集型的(例如，存储器资源密集型)。有状态操作的示例是连接，无状态操作的示例是过滤器。
在相关实施例中，应用程序(在云系统100中执行)基于一个或多个聚类标准被聚类并且不同的机器学习的模型被训练并用于每个聚类。
集群标准的示例包括应用程序执行的有状态操作的数量和/或应用程序在一段时间内接收的请求的数量。
在相关实施例中，机器学习的模型被训练并用于单独的应用程序。例如，机器学习的模型A根据应用程序A的性能数据进行训练，并用于为应用程序A(以及可能的云应用程序A的未来版本)做出重调大小的决策，而机器学习的模型B基于来自应用程序B的性能数据训练，并且用于为应用程序B做出重调大小的决策。
在一个实施例中，机器学习的模型被训练并用于确定至少一个计算机资源(例如，存储器)的重调大小量，并且一个或多个规则被用于确定至少一个其他计算机资源(例如CPU)的重调大小量。
对存储器重调大小
在一个实施例中，机器学习的模型被训练并用于针对应用程序计算新的存储器分配。这种机器学习的模型的输出可以因实施方式而异。此类输出的示例包括实际的新存储器分配、实际新存储器申请的日志、存储器分配与当前存储器分配相比的绝对变化(增加或减少)(例如，增加10GB或减少5GB)，或存储器分配的相对变化(例如，+37％或-22％)。存储器分配的相对变化在云环境中很有用，在云环境中，一个应用程序与另一个应用程序之间的存储器分配差异很大。
在相关实施例中，单个机器学习的模型输出一组用于特定应用程序的分配。因此，输出包括多个资源分配，每个资源分配用于不同类型的计算机资源，例如存储器、堆、CPU等。用于这种机器学习的模型的训练数据是通过利用手动调整的应用程序来确保分配的是准确的来获得。因为该模型是预测模型，它的准确性可以通过使用标准度量来衡量，例如均方根误差(RMSE)和其他对供应不足而不是过度供应进行惩罚的准确性度量(例如，加权RMSE)。
在针对不同类型的存储器(例如，堆存储器和总存储器)存储不同策略的实施例中，第一机器学习的模型被训练并用于确定第一类型存储器的新分配，并且第二机器学习的模型被训练并用于确定第二类存储器的新分配。在该实施例中，第二机器学习的模型的输入之一可以是第一类型存储器的当前分配。换句话说，第一类型存储器的当前分配是第二机器学习的模型的特征。例如，如果堆存储器的当前分配是5GB，则5GB是用于确定总存储器的新分配的第二机器学习的模型的输入。
并行度和积压
在一个实施例中，用于确定是增加还是减少应用程序的并行度的一个度量是应用程序的积压。应用程序的“积压”是指等待应用程序执行的工作量。应用程序的积压可以根据云系统100已经针对应用程序接收到但应用程序尚未处理的消息(例如，包括请求)或事件的数量来衡量。例如，如果云系统100已接收到应用程序已订阅的98个事件并且应用程序已处理这98个事件中的两个，则积压为96。替代地，可以不仅基于消息或事件的数量来衡量积压，而且还可基于消息或事件的类型来衡量积压。例如，一些类型的事件可以比其他类型的事件花费更长的时间来处理(例如，平均而言)。因此，应用程序处理1000个A类事件所花的时间可以与处理3个B类事件所花的时间一样长。
测量积压的一种方式是利用(1)由应用程序写入(例如，写入到存储118或事件处理平台(例如，Kafka)的检查点和(2)指示以应用程序或应用程序容器为目的地的最近事件或消息的流结束数据。数据收集器122可以通过事件处理平台(例如Kafka)的元数据服务访问流结束数据。流结束数据可以与应用程序或应用程序容器本地的缓冲区不同。单独的进程可以在本地缓冲区中放置事件处理平台已排队(例如，基于每个主题)的事件或消息。应用程序可以直接访问本地缓冲区以便获得下一个事件或消息以进行处理。这样，应用程序就不需要针对以应用程序为目的地的每个事件/消息而向事件处理平台发送单独的请求，针对以应用程序为目的地的每个事件/消息而向事件处理平台发送单独的请求会增加事件/消息取回延迟。
由应用程序写入的检查点可以在存储118中(其可被数据收集器122访问)或者可以是应用程序使用事件处理平台发布的具有特定主题的消息。由数据收集器122使用检查点来确定已经由应用程序处理的最新事件/消息。检查点可以包括唯一地标识应用程序完全处理的最近事件/消息的第一值(例如，数字)。流结束数据可以包括第二值，该第二值唯一地标识云系统100已经接收到的应用程序的最近事件/消息。第二值和第一值之间的差异指示云系统100已经针对应用程序接收到但尚未被应用程序处理的事件/消息的数量。
在一个实施例中，用于并行度的策略包括一个或多个启动标准，每个启动标准都基于对积压的单个测量。例如，如果积压是一千条消息，则将并行度提高2倍；如果积压是一万条消息，则将并行度提高4倍。
然而，应用程序积压的单次测量可能不会产生足够的信息来确定是增加还是减少应用程序的并行度。因此，在一个实施例中，积压的变化被确定并用于确定是否触发与并行度相关联的策略的动作。例如，在时间T1，应用程序的积压可以是43，而在时间T2，应用程序的积压可以是45。增加两个(或5％)的增加可能不足以增加并行度。但是，积压增加10％可以触发并行度增加25％，而积压增加30％可能会触发并行度增加2倍。
增加积压的启动标准可以包括绝对变化、百分比变化和/或绝对大小。例如，即使一段时间内积压的增加仅为5％，如果积压的大小大于N，则触发增加并行度动作。
将远程服务的性能问题与应用程序性能问题相关联
一些应用程序，作为其逻辑的一部分，可以异步或同步地与远程服务通信。远程服务的示例包括远程网络服务、远程BLOB(二进制大对象)存储和远程KV(键值)存储。远程服务的一个问题是远程服务可能会失败或者它们的性能可能会下降。例如，远程服务可能不会以应用程序请求的数据进行响应。作为另一示例，远程服务可能支持的每秒查询数(QPS)可能降低50％。作为另一示例，将云系统100与远程服务通信连接的计算机网络可能开始丢弃5％的数据包。作为另一个示例，远程服务的平均延迟可能从一毫秒增加到八毫秒。由于任何这些性能下降，应用程序的延迟都会增加。
响应于应用程序延迟的增加，重调大小控制器120可以通过启动应用程序的新实例来增加CPU到应用程序的分配或增加并行度。这些重调大小动作不仅不会解决远程服务问题，而且这些重调大小动作可能通过向远程服务发送更多请求来降低远程服务的性能。
在一个实施例中，远程服务的性能与应用程序的性能相关。如果这两个性能正在下降并且相关，则远程服务很可能是应用程序性能问题的原因。在这种情况下，不是考虑某些策略，而是跳过这些策略。例如，策略引擎124“关闭”与CPU和并行度相关的策略(并因此不考虑这些策略)，同时保持与堆和存储器相关的策略“开启”(并因此考虑那些策略)。
可以以一种或多种方式确定远程服务的性能。例如，使得将请求传输到远程服务的应用程序可以接收到请求未到达远程服务的响应。应用程序可以记录一段时间内此类故障发生的次数。作为另一示例，应用程序可以记录在向远程服务发送请求和从远程服务接收响应之间流逝的时间量。应用程序(或另一计算元件)可以计算差异，这指示每个请求-响应对的延迟的测量。随着时间的推移跟踪单个请求-响应对的延迟可以揭示与远程服务相关的延迟增加。作为另一示例，远程服务可以向应用程序报告远程服务当前提供的服务级别。服务级别可以是任何形式，例如0到10的范围内的值、延迟值或QPS值。基于服务级别，应用程序(或策略引擎124)可以确定远程服务何时表现不佳。
重调大小控制器120将远程服务的性能与应用程序的性能相关联的一种方式是跟踪一段时间内应用程序对一个或多个计算机资源中的每一个的性能的百分比变化，并计算在同一时间段内远程服务的性能的百分比变化。可以计算基于两组性能数据的相关性统计量度，其反映相关性水平。相关性度量的示例包括时滞互相关和逐步回归。此外，应用程序的性能相对于远程服务的性能可以在时间上发生偏移，因为前者通常滞后于后者，尤其是在存在因果关系的情况下。性能数据的这种及时偏移可以产生更强和更可靠的相关性度量。
图2B是描绘在一个实施例中用于在确定要考虑哪些策略时将由应用程序使用的远程服务的性能考虑在内的示例过程270的流程图。过程270可以在图2A中的框230之前，或者是框230的一部分。例如，不再考虑通常本应基于优先顺序考虑的策略，至少直到在框276中做出特定确定。
在框272，确定应用程序正在使用的远程服务的性能。可以使用此处描述的任何性能度量。
在框274，确定应用程序的性能。可以使用应用程序的任何性能度量，例如延迟、QPS、错误和/或资源利用率度量。
在框276，确定各个性能是否相关。例如，如果远程服务的性能显著下降紧接在应用程序性能的显著下降之前，并且两者的性能不佳持续了一段时间(例如，几分钟)，则很可能远程服务和应用程序的性能是相关的。
在框278，一个或多个策略相对于应用程序被“关闭”。框278可以涉及关于应用程序关闭所有策略或仅关闭某些策略。例如，关闭的策略是与一种或多种特定类型的计算机资源有关的策略。
框278可以涉及存储关闭数据，关闭数据将一个或多个策略与应用相关联并且指示策略引擎124在确定接下来针对应用程序考虑哪个策略时不应考虑该一个或多个策略。如果已经针对关于应用程序的一个或多个策略存储了关闭数据，则框278可以涉及仅检查关闭数据并且可选地生成指示该事件的记录。
在框280，关于应用程序“开启”一个或多个策略。框280可以涉及关于应用程序开启所有策略或仅开启某些策略。例如，开启的策略是与一种或多种特定类型的计算机资源有关的策略。
如果已经针对关于应用程序的一个或多个策略存储了关闭数据，则框280可以涉及删除关闭数据并且可选地生成指示该删除的记录。如果尚未存储关闭数据，则框280可涉及仅检查是否存在关闭数据并进行到图2A的框230。
时间窗
在一个实施例中，一个或多个策略中的每个策略与时间窗相关联。时间窗指示不考虑相对应的策略(或不考虑策略的启动标准)的时间段。相反，在那个时间段期间，数据收集器122可以继续获得关于不同类型的计算机资源的性能相关数据。例如，如果策略与30分钟的时间窗相关联并且时间段的开始是在时间T1并且时间段的结束时间是时间T3，并且在时间T2(在T1和T3之间)选择策略，然后策略引擎124确定T2在T3之前，因此确定不考虑策略的启动标准。
在多个策略与时间窗相关联的实施例中，从一个策略到另一个策略的时间窗可以相同或可以不同。例如，P1(最高优先级策略)之后的每个后续策略的时间窗可以不短于优先级顺序的前一个策略的时间窗。作为一个具体的示例，策略P1与一分钟的时间窗相关联，策略P2与两分钟的时间窗相关联，策略P3关联两分钟的时间窗，策略P4关联三十分钟的时间窗。
重置时间窗
在当前时间经过策略的时间窗之后，则该策略是供考虑的候选者。在一个实施例中，响应于确定要执行与策略相关联的动作而重置策略的时间窗。例如，满足与策略P2相关联的启动标准，并且因此执行策略P2的动作A2。时间T2是确定满足启动标准或动作A2完成的时间。策略P2的时间窗被重置为开始于T2并结束于时间T3，该时间T3基于时间窗(例如，两分钟)和时间T2的总和。因此，直到当前时间在时间T3或在时间T3之后为止，策略P2才成为考虑的候选者。
在一个实施例中，响应于特定策略的动作被触发或执行，重置在优先级顺序中在特定策略之后的任何策略的时间窗。例如，执行策略P3的动作。作为响应，重置策略P3-P8中的每个的时间窗，无论该时间窗是否已经过去。
在每个后继策略的时间窗在优先级顺序上不短于前一个策略并且当特定策略的动作被执行时在特定策略之后的每个后继策略的时间窗重置的实施例中，如果策略引擎124确定不应考虑特定策略，因为当前时间在特定策略的时间窗内，则策略引擎124可以避免考虑任何后续策略，因为当前时间将在它们各自的时间窗内。因此，策略引擎124可以在未来的时间返回到考虑最高优先级策略(例如，策略P1)。
缩小
缩小策略与放大策略类似地起作用并且旨在从应用程序回收资源而不影响它们的性能特征。缩小策略旨在避免依赖通过处理放大策略发出的补救措施，从而避免由于重复连续的缩小和放大动作而引起的振荡。类似地，缩小策略可以通过避免使用附加减少策略(例如每次将当前资源分配减少固定量(例如，10％))来最小化缩小重调大小动作的次数以减少重调大小时间。相反，在一个实施例中，策略引擎124基于当前资源利用数据确定什么动作是安全的。例如，如果策略引擎124确定与特定应用程序的策略P6相关联的一个或多个启动标准得到满足并且特定应用程序当前正在使用6GB存储器，则重调大小动作是基于当前分配减少特定应用程序的存储器分配，例如将存储器分配减少到比当前存储器分配大10％的量。
堆缩小
回收堆分配呈现存储器-CPU折衷。为堆存储器选择相对较低的值会导致频繁的垃圾收集，从而增加CPU使用率，并可能增加超出应用程序要求的延迟。因此，在堆是计算机资源的实施例中，为了通过单个安全重调大小动作缩小堆分配，重调大小控制器120依赖于堆提交度量。该度量由Java虚拟机(JVM)发布，用于衡量JVM分配的用于处理活动对象的堆的数量以及用于簿记和预期的未来垃圾收集的额外空间。因此，如果应用程序使用的堆量为3GB，提交的堆量为4GB，并且应用程序的当前堆为10GB，则将堆分配减少到3.5GB将使得应用程序提高其CPU利用率。响应于确定执行重调大小动作而缩小应用程序的堆分配的规则的示例是比当前堆提交度量大一定百分比(例如，5)。通过使用堆提交度量来限制堆分配，安全的缩小堆策略可以最大限度地减少缩小重调大小动作对应用程序现有特征的影响，并最大限度地减少需要以过度分配为代价的补救措施。
硬件概览
根据一个实施例，本文描述的技术由一个或多个专用计算设备实现。专用计算设备可以硬连线来执行这些技术，或者可以包括数字电子设备，例如一个或多个专用集成电路(ASIC)或现场可编程门阵列(FPGA)，这些设备被持续编程以执行技术，或者可以包括一个或多个通用硬件处理器，该处理器被编程为根据固件、存储器、其他存储或组合中的程序指令来执行这些技术。这种专用计算设备还可以将定制的硬连线逻辑、ASIC或FPGA与定制编程相结合，以实现这些技术。专用计算设备可以是台式计算机系统、便携式计算机系统、手持设备、网络设备或结合硬连线和/或程序逻辑以实现这些技术的任何其他设备。
例如，图3是说明可在其上实施本发明的实施例的计算机系统300的框图。计算机系统300包括总线302或用于传送信息的其他通信机制，以及与总线302耦合用于处理信息的硬件处理器304。硬件处理器304例如可以是通用微处理器。
计算机系统300还包括耦合到总线302的主存储器306，例如随机存取存储器(RAM)或其他动态存储设备，用于存储要由处理器304执行的信息和指令。主存储器306也可以是用于在执行要由处理器304执行的指令期间存储临时变量或其他中间信息。这样的指令，当存储在处理器304可访问的非暂时性存储介质中时，使计算机系统300成为定制成执行指令中指定的操作的专用机器。
计算机系统300还包括耦合到总线302的只读存储器(ROM)308或其他静态存储设备，用于存储用于处理器304的静态信息和指令。存储设备310，例如磁盘、光盘或固态驱动器，被提供并耦合到总线302以用于存储信息和指令。
计算机系统300可以经由总线302耦合到显示器312，例如阴极射线管(CRT)，用于向计算机用户显示信息。包括字母数字键和其他键的输入设备314耦合到总线302，用于将信息和命令选择传送到处理器304。另一种类型的用户输入设备是光标控件316，例如鼠标、轨迹球或光标方向键，用于将方向信息和命令选择传送到处理器304并用于控制显示器312上的光标移动。该输入设备通常在两个轴上具有两个自由度，第一轴(例如，x)和第二轴(例如，y)，即允许设备指定平面中的位置。
计算机系统300可以使用定制的硬连线逻辑、一个或多个ASIC或FPGA、固件和/或程序逻辑来实现这里描述的技术，这些定制的硬连线逻辑、一个或多个ASIC或FPGA、固件和/或程序逻辑与计算机系统相结合导致或编程计算机系统300成为特殊用途的机器。根据一个实施例，本文的技术由计算机系统300响应于处理器304执行包含在主存储器306中的一个或多个指令的一个或多个序列而执行。此类指令可从诸如存储设备310的另一存储介质读入主存储器306。包含在主存储器306中的指令序列的执行导致处理器304执行这里描述的过程步骤。在备选实施例中，硬连线电路可用于代替软件指令或与软件指令结合使用。
如本文所用，术语“存储介质”是指存储使机器以特定方式操作的数据和/或指令的任何非暂时性介质。这样的存储介质可以包括非易失性介质和/或易失性介质。非易失性介质包括例如光盘、磁盘或固态驱动器，例如存储设备310。易失性介质包括动态存储器，例如主存储器306。存储介质的常见形式包括例如软盘、柔性盘、硬盘、固态驱动器、磁带或任何其他磁性数据存储介质、CD-ROM、任何其他光学数据存储介质、任何带有孔图案的物理介质、RAM、PROM和EPROM、FLASH-EPROM、NVRAM、任何其他存储芯片或盒式磁带。
存储介质不同于传输介质，但可以与传输介质结合使用。传输介质参与存储介质之间的信息传递。例如，传输介质包括同轴电缆、铜线和光纤，包括构成总线302的电线。传输介质也可以采用声波或光波的形式，例如在无线电波和红外数据通信期间产生的那些。
各种形式的介质可以涉及将一个或多个指令的一个或多个序列携带到处理器304以供执行。例如，指令最初可以承载在远程计算机的磁盘或固态驱动器上。远程计算机可以将指令加载到其动态存储器中，并使用调制解调器通过电话线发送指令。计算机系统300本地的调制解调器可以接收电话线上的数据并使用红外发射器将数据转换为红外信号。红外检测器可以接收红外信号中携带的数据并且适当的电路可以将数据放置在总线302上。总线302将数据携带到主存储器306，处理器304从主存储器306取回并执行指令。由主存储器306接收的指令可以可选地在处理器304执行之前或之后存储在存储设备310上。
计算机系统300还包括耦合到总线302的通信接口318。通信接口318提供耦合到连接到本地网络322的网络链路320的双向数据通信。例如，通信接口318可以是综合服务数字网(ISDN)卡、电缆调制解调器、卫星调制解调器或用于为相应类型的电话线提供数据通信连接的调制解调器。作为另一个示例，通信接口318可以是局域网(LAN)卡以提供到兼容LAN的数据通信连接。也可以实现无线链路。在任何这样的实施方式中，通信接口318发送和接收携带表示各种类型信息的数字数据流的电、电磁或光信号。
网络链路320通常通过一个或多个网络向其他数据设备提供数据通信。例如，网络链路320可以通过本地网络322提供到主计算机324或到由因特网服务提供商(ISP)326操作的数据设备的连接。ISP 326又通过全球分组数据通信网络(现在通常称为“因特网”)328来提供数据通信服务。本地网络322和因特网328都使用携带数字数据流的电、电磁或光信号。通过各种网络的信号和网络链路320上的信号以及通过携带数字数据进出计算机系统300的通信接口318的信号是传输介质的示例形式。
计算机系统300可以通过网络、网络链路320和通信接口318发送消息和接收数据，包括程序代码。在因特网示例中，服务器330可以通过因特网328、ISP 326、本地网络322和通信接口318发送用于应用程序的请求代码。
接收到的代码可以在其被接收时由处理器304执行，和/或存储在存储设备310或其他非易失性存储器中以供稍后执行。
在前述说明书中，本发明的实施例已经参考许多特定细节进行了描述，这些细节可能因实施方式而异。因此，说明书和附图被认为是说明性的而不是限制性的。本发明范围的唯一和排他性指示符以及申请人意图作为本发明范围的内容，是从本申请发出的权利要求书组的字面和等同范围，以此类权利要求发出的具体形式，包括任何后续更正。

Claims (13)

1.一种方法，包括：
存储指示多个策略的顺序的策略数据，其中，所述多个策略包括(1)对应于第一计算机资源和第一重调大小动作的第一策略，以及(2)第二策略，所述第二策略优先级低于所述第一策略并且对应于第二重调大小动作和不同于所述第一计算机资源的第二计算机资源；
在存储所述策略数据之后，从在云环境中执行的多个应用程序中的至少一个应用程序接收计算机资源利用数据；
基于所述策略数据中指示的顺序，识别所述第一策略；
基于所述计算机资源利用数据的第一部分，关于所述应用程序确定是否满足与所述第一策略相关联的一个或多个第一标准；
如果满足所述一个或多个第一标准，则使得关于所述应用程序和所述第一计算机资源执行所述第一重调大小动作而不考虑所述第二策略；
如果不满足所述一个或多个第一标准，则基于所述计算机资源利用数据的第二部分，关于所述应用程序确定是否满足与所述第二策略相关联的一个或多个第二标准；
其中，所述方法由一个或多个计算设备执行。
2.如权利要求1所述的方法，其中，所述第一计算机资源是存储器并且所述第二计算机资源是一个或多个中央处理单元(CPU)。
3.如权利要求1所述的方法，其中，所述第一计算机资源是一个或多个中央处理单元(CPU)并且所述第二计算机资源是并行度。
4.如权利要求1所述的方法，还包括：
存储时间窗数据，所述时间窗数据针对所述多个策略中的每个策略指示时间窗，所述时间窗指示何时不考虑所述每个策略来确定是否满足与所述每个策略相关联的一个或多个标准；
在基于所述计算机资源利用数据确定是否满足与所述第一策略关联的所述一个或多个第一标准之前：
确定当前时间；
从所述时间窗数据中识别与所述第一策略相关联的第一时间窗；
只有在确定所述当前时间不在所述第一时间窗内之后，才基于所述计算机资源利用数据确定是否满足与所述第一策略关联的一个或多个第一标准。
5.如权利要求4所述的方法，其中，所述多个策略中的所述第一策略的每个后续策略的时间窗不短于与所述多个策略中的紧邻的先前策略相关联的时间窗。
6.如权利要求4所述的方法，还包括：
响应于确定满足所述一个或多个第一标准，针对所述多个策略中的每个策略更新所述时间窗。
7.如权利要求1所述的方法，其中，所述计算机资源利用数据包括(a)日志文件中指示特定应用程序已处理的第一数据的检查点和(b)指示为所述特定应用程序缓冲的第二数据的缓冲数据，所述方法还包括：
基于所述检查点和所述缓冲数据，确定所述第一数据和所述第二数据之间的输入的量；
基于所述输入的量，确定是增加还是减少所述特定应用程序的并行度。
8.如权利要求1所述的方法，还包括：
基于所述计算机资源利用数据，关于所述应用程序确定是否满足与第三策略相关联的一个或多个第三标准，其中，所述第三策略对应于堆存储器并且与缩小动作相关联；
其中，确定是否满足所述一个或多个第三标准包括确定针对所述应用程序提交的堆存储器的量，其中，提交的堆存储器的量大于用于所述应用程序的堆存储器的量。
9.如权利要求1所述的方法，还包括：
基于所述计算机资源利用数据，确定增加所述应用程序的并行度；
响应于确定增加所述应用程序的并行度：
确定如果将附加线程计数添加到所述应用程序的当前线程计数则是否会达到最大线程阈值；
响应于确定将达到所述最大线程阈值，使得所述应用程序的新实例在云环境中执行。
10.如权利要求1所述的方法，其中，所述第一计算机资源是堆存储器，并且所述第二计算机资源是非堆存储器。
11.如权利要求1所述的方法，还包括，响应于确定满足所述一个或多个第一标准：
识别与所述应用程序或所述第一计算机资源相关联的多个特征值；
将所述多个特征值输入到已经使用一种或多种机器学习技术基于多个特征训练的机器学习的模型中，其中，所述机器学习的模型生成输出；
其中，所述第一重调大小动作与所述第一计算机资源的重调大小的量相关联，其中，所述重调大小的量基于所述输出。
12.如权利要求1所述的方法，其中：
所述多个策略包括顺序低于所述第一策略和第二策略的多个策略；
基于顺序的所述多个策略中的最后一个策略仅在确定未满足与所述多个策略中所述最后一个策略之前的每个策略相关联的一个或多个启动标准之后才被考虑。
13.一种或多种存储指令的存储介质，当所述指令由一个或多个处理器执行时，使得执行如权利要求1-12中任一项所述的方法。
CN202180046873.4A 2020-06-30 2021-05-28 用于流处理应用程序的自动调整大小 Pending CN115803716A (zh)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US16/917,737 US11487588B2 (en) 2020-06-30 2020-06-30 Auto-sizing for stream processing applications
US16/917,737 2020-06-30
PCT/US2021/034681 WO2022005665A1 (en) 2020-06-30 2021-05-28 Auto-sizing for stream processing applications

Publications (1)

Publication Number Publication Date
CN115803716A true CN115803716A (zh) 2023-03-14

Family

ID=76624171

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202180046873.4A Pending CN115803716A (zh) 2020-06-30 2021-05-28 用于流处理应用程序的自动调整大小

Country Status (4)

Country Link
US (1) US11487588B2 (zh)
EP (1) EP4172769A1 (zh)
CN (1) CN115803716A (zh)
WO (1) WO2022005665A1 (zh)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11687380B2 (en) * 2020-09-10 2023-06-27 International Business Machines Corporation Optimizing resource allocation for distributed stream processing systems
US12079659B2 (en) * 2020-12-15 2024-09-03 International Business Machines Corporation Selection of stream management operations based on machine learning in a distributed computing environment
US11954506B2 (en) * 2021-03-29 2024-04-09 International Business Machines Corporation Inspection mechanism framework for visualizing application metrics
US20240193012A1 (en) * 2022-07-05 2024-06-13 Rakuten Symphony Singapore Pte. Ltd. Correlation and policy engine system and method of operation

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9329904B2 (en) 2011-10-04 2016-05-03 Tier 3, Inc. Predictive two-dimensional autoscaling
US10148592B1 (en) 2015-06-29 2018-12-04 Amazon Technologies, Inc. Prioritization-based scaling of computing resources
US10996991B2 (en) * 2017-11-29 2021-05-04 Red Hat, Inc. Dynamic container-based application resource tuning and resizing

Also Published As

Publication number Publication date
WO2022005665A1 (en) 2022-01-06
US11487588B2 (en) 2022-11-01
EP4172769A1 (en) 2023-05-03
US20210406086A1 (en) 2021-12-30

Similar Documents

Publication Publication Date Title
US10592522B2 (en) Correlating performance data and log data using diverse data stores
CN115803716A (zh) 用于流处理应用程序的自动调整大小
US11171849B2 (en) Collecting samples hierarchically in a datacenter
US7685251B2 (en) Method and apparatus for management of virtualized process collections
US9424098B2 (en) Dynamic resource scheduling
US7882216B2 (en) Process and methodology for generic analysis of metrics related to resource utilization and performance
US9026837B2 (en) Resource aware placement of applications in clusters
US10972555B2 (en) Function based dynamic traffic management for network services
WO2020134364A1 (zh) 一种虚拟机迁移方法、云计算管理平台和存储介质
US10956214B2 (en) Time frame bounded execution of computational algorithms
US9792231B1 (en) Computer system for managing I/O metric information by identifying one or more outliers and comparing set of aggregated I/O metrics
CN115373835A (zh) Flink集群的任务资源调整方法、装置及电子设备
CN116391175A (zh) 自动缩放用于企业级大数据工作负载的查询引擎
CN111782341A (zh) 用于管理集群的方法和装置
US11599441B2 (en) Throttling processing threads
US10721181B1 (en) Network locality-based throttling for automated resource migration
KR20030041612A (ko) 서버 병목을 실시간으로 분석하는 방법
US20240256347A1 (en) Apparatus and method for detection, triaging and remediation of unreliable message execution in a multi-tenant runtime
US20230125503A1 (en) Coordinated microservices
WO2023039711A1 (en) Efficiency engine in a cloud computing architecture
Kalim Satisfying service level objectives in stream processing systems
Sidhanta et al. Infra: SLO Aware Elastic Auto-scaling in the Cloud for Cost Reduction
Kalim Henge: An intent-driven scheduler for multi-tenant stream processing

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination