CN116643875A - 一种任务调度方法、服务器及服务器集群 - Google Patents

一种任务调度方法、服务器及服务器集群 Download PDF

Info

Publication number
CN116643875A
CN116643875A CN202310442976.3A CN202310442976A CN116643875A CN 116643875 A CN116643875 A CN 116643875A CN 202310442976 A CN202310442976 A CN 202310442976A CN 116643875 A CN116643875 A CN 116643875A
Authority
CN
China
Prior art keywords
computing
resource
type
resources
application
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
CN202310442976.3A
Other languages
English (en)
Inventor
胡耀国
吴祥智
周新中
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.)
XFusion Digital Technologies Co Ltd
Original Assignee
XFusion Digital Technologies Co Ltd
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 XFusion Digital Technologies Co Ltd filed Critical XFusion Digital Technologies Co Ltd
Priority to CN202310442976.3A priority Critical patent/CN116643875A/zh
Publication of CN116643875A publication Critical patent/CN116643875A/zh
Pending legal-status Critical Current

Links

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
    • 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/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • 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/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
    • 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
    • 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

Abstract

本申请公开了一种任务调度方法、服务器及服务器集群，涉及计算技术领域，能够考虑到应用的性能需求，提高资源的利用率，提升HPC集群吞吐量和性能。方法应用于管理节点，管理节点与至少一个计算节点连接，方法包括：获取多个应用的类型；其中，不同类型的应用对计算资源的敏感程度不同；基于多个应用的类型，对计算节点中的计算资源进行配置，得到资源表；其中，资源表中包括多个计算资源类型，计算资源类型与应用的类型存在对应关系，多个计算资源类型之间存在资源约束，计算资源类型由应用在不同计算资源下的性能测试结果确定；在管理节点接收目标应用下发的任务后，基于目标应用所属的类型和资源表，为目标应用下发的任务分配计算资源。

Description

一种任务调度方法、服务器及服务器集群
技术领域
本申请涉及计算技术领域，尤其涉及一种任务调度方法、服务器及服务器集群。
背景技术
高性能计算(high performance computing，HPC)领域的并行计算程序的性能是由中央处理器(central processing unit，CPU)核数、单核浮点性能、内存带宽、网络带宽和时延，以及存储带宽和时延综合决定。在HPC领域的非交互式计算中，应用下发的任务通常被提交到调度器，调度器先评估任务需要的计算资源和执行的优先级，再将任务分配到合适的节点上执行。
在一些传统技术中，HPC集群在执行多个任务前，多个任务已预先被配置资源(例如CPU核数、CPU socket、图形处理器(graphics processing unit，GPU)、内存等)，当多个任务被提交到调度器后，调度器基于多个任务所配置的资源，将每个任务分配到资源充足的节点上。但是传统技术存在资源浪费，资源利用率较低，集群吞吐量和性能较低的问题。
发明内容
本申请实施例提供了一种任务调度方法、服务器及服务器集群，能够考虑到应用的性能需求，提高资源的利用率，提升HPC集群吞吐量和性能。
为实现上述技术目的，本申请实施例采用如下技术方案：
第一方面，本申请实施例提供了一种任务调度方法，应用于管理节点，管理节点与至少一个计算节点连接，方法包括：获取多个应用的类型；其中，不同类型的应用对计算资源的敏感程度不同；基于多个应用的类型，对计算节点中的计算资源进行配置，得到资源表；其中，资源表中包括多个计算资源类型，计算资源类型与应用的类型存在对应关系，多个计算资源类型之间存在资源约束，计算资源类型由应用在不同计算资源下的性能测试结果确定；在管理节点接收目标应用下发的任务后，基于目标应用所属的类型和资源表，为目标应用下发的任务分配计算资源。
可以理解的是，由于不同应用对计算资源的敏感程度不同，因此可以将对计算资源的敏感程度不同的应用分为不同的类别，并基于应用的类别，为该类别的应用配置满足该类别应用性能的计算资源，以此来解决传统技术中因未考虑应用性能导致资源浪费的问题，提高了资源利用率、集群吞吐量和性能。
在一种可能的实现方式中，至少一个计算节点中设置了每个计算资源类型对应的任务队列；每个计算资源类型对应的任务队列关联了每个计算资源类型和每个计算资源类型对应的应用的类型；为目标应用下发的任务分配计算资源，包括：将目标应用下发的任务提交到至少一个计算节点的目标任务队列，以使得至少一个计算节点为目标应用下发的任务分配目标任务队列所关联的计算资源；目标任务队列关联了目标应用的类型和目标应用的类型对应的计算资源类型。
可以理解的是，上述方法中在计算节点中设置了不同的任务队列，不同的任务队列关联不同类型的计算资源，以此来实现为不同类型的应用下发的任务分配对应类型的计算资源的目的。该方法通过任务队列关联固定分配好的计算资源，能够将固定分配好的计算资源隔离开，并与每类应用绑定，避免计算节点在同时执行多个任务时发生资源争抢。
在另一种可能的实现方式中，计算资源包括内存带宽；多个应用的类型包括：第一类应用、第二类应用和第三类应用；其中，第一类应用对内存带宽的敏感程度小于第一阈值；第二类应用对内存带宽的敏感程度大于或等于第一阈值，且小于第二阈值；第三类应用对内存带宽的敏感程度大于或等于第二阈值；第一阈值小于第二阈值；多个计算资源类型包括：第一类资源、第二类资源和第三类资源；其中，第一类资源的单核内存带宽小于第一带宽阈值；第二类资源的单核内存带宽大于等于第一带宽阈值，且小于第二带宽阈值；第三类资源的单核内存带宽大于等于第二带宽阈值；第一带宽阈值小于第二带宽阈值；第一类应用对应第一类资源；第二类应用对应第二类资源；第三类应用对应第三类资源。
可以理解的是，若应用分为三类，则计算资源对应分为三类。该方法能够将每种类型的应用性能的需求固定分配好，避免资源浪费，提高节点的吞吐量。
在另一种可能的实现方式中，计算资源还包括CPU核数；第一类资源所包括的CPU核数和内存带宽，以及第三类资源所包括的CPU核数和内存带宽，是基于多个第一类应用在CPU上运行时的平均单核内存带宽、多个第三类应用在CPU上运行时的平均单核内存带宽、计算节点的内存带宽和计算节点的CPU核数确定的。
可以理解的是，由于计算资源类型之间存在资源约束，由此可知第一类资源和第三类资源互相约束。在进行资源配置时不仅涉及内存带宽，还涉及CPU核数或其他资源，因此，本申请实施例还提出了一种CPU核数计算的方法，该方法能快速同时计算第一类资源和第三类资源所包括的CPU核数。
在另一种可能的实现方式中，第一类资源所包括的CPU核数core1和内存带宽BW1，第三类资源所包括的CPU核数core2和内存带宽BW2，多个第一类应用在CPU上运行时的平均单核内存带宽bw1、多个第三类应用在CPU上运行时的平均单核内存带宽bw2、计算节点的内存带宽BW和计算节点的CPU核数CORE之间满足如下公式：core2＝(BW-CORE*bw1)/(bw2-bw1)；core1＝CORE-core2；BW1＝core1*bw1；BW2＝core2*bw2。
可以理解的是，上述方法是本申请实施例提出的一种具体计算CPU核数的方法。该方法实现简单，可操作性高。
在另一种可能的实现方式中，计算资源还包括LLC Way数；第一类资源所包括的LLC Way数是基于第一类资源所包括的CPU核数、至少一个第一类应用的执行性能和计算节点的LLC Way数确定的；其中，执行性能是基于LLC Way数，执行至少一个第一类应用得到的第一类应用的性能；第三类资源所包括的LLC Way数是基于第一类资源所包括的LLC Way数和计算节点的LLC Way数确定的。
在另一种可能的实现方式中，对计算节点中的计算资源进行配置，包括：获取第一类资源的候选LLC Way数，并依次减少或增加第一类资源的候选LLC Way数，得到多个待选LLC Way数；基于多个待选LLC Way数，分别执行至少一个第一类应用，得到多个执行性能；将多个执行性能中的目标执行性能对应的待选LLC Way数，配置为第一类资源所包括的LLCWay数；其中，目标执行性能是多个执行性能中性能下降达到第一预设值之前的至少一个执行性能，或者，是多个执行性能中性能上升小于第二预设值之前的至少一个执行性能。
可以理解的是，LLC Way数在一定程度上提升任务的性能，上述方法是本申请实施例提出的一种具体计算LLC Way数的方法。该方法实现简单，可操作性高。
第二方面，本申请实施例提供一种服务器集群，包括管理节点和多个计算节点；管理节点用于获取多个应用的类型；其中，不同类型的应用对计算资源的敏感程度不同；基于多个应用的类型，对计算节点中的计算资源进行配置，得到资源表；其中，资源表中包括多个计算资源类型，计算资源类型与应用的类型存在对应关系，多个计算资源类型之间存在资源约束，计算资源类型由应用在不同计算资源下的性能测试结果确定；在管理节点接收目标应用下发的任务后，基于目标应用所属的类型和资源表，为目标应用下发的任务分配计算资源；计算节点用于，使用管理节点为目标应用下发的任务分配的计算资源，执行目标应用下发的任务。
第三方面，本申请实施例提供一种管理节点，其中，管理节点应用于第一方面或第一方面中任一种可能的实现方式的任务调度方法的各个模块。
第四方面，本申请实施例提供一种服务器，包括存储器和处理器。存储器和处理器耦合；存储器用于存储计算机程序代码，计算机程序代码包括计算机指令。当处理器执行该计算机指令时，使得该服务器执行如第一方面及其任一种可能的实现方式的任务调度方法。
第五方面，本申请实施例提供一种计算机可读存储介质，该计算机可读存储介质包括计算机指令。其中，当计算机指令在服务器上运行时，使得该服务器执行如第一方面及其任一种可能的实现方式的任务调度方法。
第六方面，本申请实施例提供一种计算机程序产品，该计算机程序产品包括计算机指令。其中，当计算机指令在服务器上运行时，使得该服务器执行如第一方面及其任一种可能的实现方式的任务调度方法。
本申请实施例中第三方面到第六方面及其各种实现方式的具体描述，可以参考第一方面及其各种实现方式中的详细描述；并且，第三方面到第六方面及其各种实现方式的有益效果，可以参考第一方面及其各种实现方式中的有益效果分析，此处不再赘述。
本申请实施例的这些方面或其他方面在以下的描述中会更加简明易懂。
附图说明
图1为本申请实施例提供的任务调度方法所涉及的一种HPC集群架构图；
图2为本申请实施例提供的一种任务调度方法流程图；
图3为本申请实施例提供的一种应用性能曲线变化图；
图4为本申请实施例提供的一种资源配置方法流程图；
图5为本申请实施例提供的一种管理节点的结构示意图；
图6为本申请实施例提供的另一种服务器的结构示意图。
具体实施方式
以下，术语“第一”、“第二”和“第三”等仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”或“第三”等的特征可以明示或者隐含地包括一个或者更多个该特征。
在HPC领域的非交互式计算中，应用下发的任务通常被提交到调度器，调度器先评估任务需要的计算资源和执行的优先级，再将任务分配到合适的节点上执行。HPC集群执行任务时所表现的性能，主要由HPC集群中每个节点的CPU核数、浮点性能、内存带宽和末级缓存(last level cache，LLC)等决定。例如，任务A需要浮点性能，对内存带宽需求较弱，这种任务可以称为浮点密集型任务，该类任务的性能受限于浮点性能；任务B需要内存带宽，对浮点性能需求较弱，这种任务可以称为访存密集型任务，该类任务的性能受限于内存带宽。对于上述任务A，如果浮点性能不够，即使分配再多的内存带宽也无法提升任务A的性能；而对于任务B，如果内存带宽不够，即使分配再多的浮点性能和CPU核数，也无法提升任务B的性能。
在一些传统技术中，HPC集群在执行多个任务前，预先配置了例如CPU核数、CPUsocket、图形处理器(graphics processing unit，GPU)和内存等资源，但是对该资源的配置，存在资源浪费，资源利用率较低，集群吞吐量和性能较低的问题。
基于此，本申请实施例提出一种任务调度方法，该方法中管理节点将应用分为多种类型，并为每种类型的应用配置对应类型的计算资源，当有应用下发任务时，管理节点基于应用的类型，为该应用下发的任务分配对应类型的计算资源。
可以理解的是，由于不同应用对计算资源的敏感程度不同，因此可以将对计算资源的敏感程度不同的应用分为不同的类别，并基于应用的类别，为该类别的应用配置满足该类别应用性能的计算资源，以此来解决传统技术中因未考虑应用性能导致资源浪费的问题，提高了资源利用率、集群吞吐量和性能。
下面将结合附图对本申请实施例的实施方式进行详细描述。
请参考图1，其示出本申请实施例提供的任务调度方法所涉及的一种HPC集群架构图。如图1所示，该HPC集群包括：管理节点110和计算节点120。
管理节点110和计算节点120之间通过网络连接构成HPC集群。
管理节点110用于基于多个应用的类型，为应用配置计算节点120的计算资源。在接收上层应用下发的任务后，基于应用的类型为该应用下发的任务分配节点120的计算资源。
计算节点120用于在管理节点110的调度下，为应用下发的任务分配应用类型对应的计算资源以及执行应用下发的任务。
示例性的，管理节点110和计算节点120可以是由一台或多台具有多核处理器的服务器组成。管理节点110和计算节点120的数量可以是一个或多个，本申请实施例对每个管理节点110和计算节点120包括的服务器数量，以及管理节点110和计算节点120的数量不做限定。
可选的，管理节点110包括调度器130。
调度器130用于在管理节点110的配置下，配置包含应用类型与计算资源类型的对应关系的资源表，为应用下发的任务分配计算节点120的计算资源。调度器130可以是软件，此时调度器130具有的功能可以由管理节点110中的CPU、GPU、NPU或FPGA实现。调度器130也可以是独立的硬件设备，与管理节点110连接，或者集成在管理节点110上。
在一种可能的实施方式中，调度器130包含服务端和客户端。其中，调度器130的服务端设置管理节点110中。调度器130的客户端设置在计算节点120中。调度器130的客户端用于收集计算节点上的计算资源总量和使用情况，并上报给管理节点上的服务端。服务端基于客户端收集的计算资源使用情况，对计算节点120的计算资源进行管理和监控。同时，服务端基于接收的任务，确定任务需要的计算资源，以及能够提供该计算资源的计算节点120，生成指令下发给对应计算节点120上的客户端，客户端接收到指令后，启动分配计算节点120上的计算资源，执行任务的命令。
上述计算资源包含CPU芯片上的CPU核数、内存带宽和LLC等资源，也可以包含在GPU、嵌入式神经网络处理器(neural-network processing units，NPU)或现场可编程逻辑门阵列(field programmable gate array，FPGA)等芯片上的计算资源。
下文对本申请实施例提供的任务调度方法进行说明。
请参考图2，为本申请实施例提供的一种任务调度方法流程图。该方法应用于管理节点，管理节点与至少一个计算节点连接。如图2所示，该方法可以包括S101-S103。
S101：管理节点获取多个应用的类型。
其中，不同类型的应用对计算资源的敏感程度不同。
计算资源包括但不限于CPU核数、内存带宽和/或LLC Way数。
若计算资源包括内存带宽，可以基于应用对内存带宽的敏感程度，将多个应用分为至少三种类型包括：第一类应用、第二类应用和第三类应用；其中，第一类应用对内存带宽的敏感程度小于第一阈值；第二类应用对内存带宽的敏感程度大于或等于第一阈值，且小于第二阈值；第三类应用对内存带宽的敏感程度大于或等于第二阈值。
应用对计算资源的敏感程度与应用的性能有关。为便于表述，下文可以将第一类应用定义为RA应用，第二类应用定义为RB应用，第三类应用定义为RC应用。
对内存带宽敏感程度小于第一阈值的应用属于RA应用，RA应用对内存敏感程度较低，当对该RA应用增加内存带宽时，该RA应用的性能提升程度较小。
对内存带宽敏感程度大于等于第一阈值且小于第二阈值的属于RB应用，RB应用对内存敏感程度中等，当对该RB应用增加内存带宽时，该RB应用的性能提升程度中等。
对内存带宽敏感程度大于等于第二阈值的属于RC应用，RC应用对内存敏感程度较高，当对该RC应用增加内存带宽时，该RC应用的性能提升程度较大。
以下提出两种对应用分类的方法：
在一种可能的实现方法中，对任意一个应用分类的方法包括S101a-S101c：
S101a：管理节点使用内存带宽测试工具stream测试单个CPU或单个节点的最大内存带宽。
S101b：管理节点将任意一个应用在单个CPU或单个节点上运行，计算任意一个应用在一段时间内的平均内存带宽。
S101c：管理节点计算任意一个应用的平均内存带宽占单个CPU或单个节点的最大内存带宽的百分比。
当该百分比小于第一阈值，则定义在该范围内的应用属于RA应用。
当该百分比在[第一阈值，第二阈值]之间，则定义在该范围内的应用属于RB应用。
当该百分比大于第二阈值，则定义在该范围内的应用属于RC应用。
在一个示例中，上述第一阈值可以取25％，第二阈值可以取50％。
在另一种可能的实现方法中，通过Linux perf工具，intel vtune工具中的TOP-DOWN工具分析任意一个应用的微架构特征。其中，当该任意一个应用的访存阻塞占比DRAMbound小于第一阈值10％，则定义在该范围内的应用属于RA应用。当该任意一个应用的DRAMbound在[第一阈值，第二阈值]之间，则在该范围内的应用属于RB应用。当该任意一个应用的DRAM bound大于第二阈值，则定义在该范围内的应用属于RC应用。
在一个示例中，上述第一阈值可以取10％，第二阈值可以取20％。
本申请实施例中上述两种分类方法均基于应用对内存带宽的敏感程度将应用分为三类，上述第一阈值和第二阈值基于具体实现方法有不同的取值。实际上，可以基于应用对内存带宽的敏感程度，将应用分为四类、五类甚至更多类。可扩展的，对于其他计算资源，可以用类似的方法对应用进行分类。
本申请实施例对应用的分多少类不做限定。上述两种分类方法可以由管理节点执行，或用户在其他设备上使用上述工具对应用进行分类后发送给管理设备，本申请实施例对上述S101a-S101c的具体执行主体不做限定。
S102：管理节点基于多个应用的类型，对计算节点中的计算资源进行配置，得到资源表。
其中，资源表中包括多个计算资源类型，计算资源类型与应用的类型存在对应关系，多个计算资源类型之间存在资源约束，计算资源类型由应用在不同计算资源下的性能测试结果确定。
当基于应用对计算资源敏感程度将应用分为三类时，计算资源如内存带宽也可以对应分为三类。多个计算资源类型包括：第一类资源、第二类资源和第三类资源；其中，第一类资源的单核内存带宽小于第一带宽阈值；第二类资源的单核内存带宽大于等于第一带宽阈值，且小于第二带宽阈值；第三类资源的单核内存带宽大于等于第二带宽阈值。第一带宽阈值小于第二带宽阈值。
资源表包括：RA应用对应第一类资源；RB应用对应第二类资源；RC应用对应第三类资源。
上述第一类资源是单核内存带宽满足RA应用性能的计算资源；第二类资源是单核内存带宽满足RB应用性能的计算资源；第三类资源是单核内存带宽满足RC应用性能的计算资源。
上述每类资源的单核内存带宽是该类资源所包括的内存带宽在该类资源所包括的CPU核上的平均值。例如，第一类资源的单核内存带宽是第一类资源所包括的内存带宽在第一类资源所包括的CPU核数上的平均值。
为便于表述，下文也可以将上述第一类资源定义为A类资源，第二类资源定义为B类资源，第三类资源定义为C类资源。
以下提出一种基于RA应用的性能测试对单核内存带宽分类的方法。
在一种可能的实现方式中，如图3所示，通过高性能共轭梯度(high performanceconjugate gradient，HPCG)工具，测试在不同单核内存带宽下，RA应用的性能相对变化情况。
从图3可以看出，在单核内存带宽小于6GB/s时，RA应用的性能的提升速度较快，在单核内存带宽大于等于9GB/s时，RA应用的性能的提升速度较慢，因此，可以取第一带宽阈值为6GB/s，取第二带宽阈值为9GB/s。
当单核内存带宽<6GB/s，该内存带宽为弱访存性计算资源，将在该范围内的单核内存带宽定义为A类资源。
当6GB/s≤单核内存带宽<9GB/s，该内存带宽为均衡性计算资源，将在该范围内的单核内存带宽定义为B类资源。
当单核内存带宽≥9GB/s的，该内存带宽为内存带宽型计算资源，将在该范围内的单核内存带宽定义为C类资源。
上述示例中基于任意RA应用在不同单核内存带宽下的性能变化情况，将单核内存带宽分为三类，该分类方法仅为一种示例，对于不同的节点，可以基于节点的实际硬件性能，对单核内存带宽进行更细致的分类，例如分为四个类型、五个类型，甚至更多。
上述可选的方法是管理节点基于应用的类型，为应用分配对应类型的计算资源。由于相同类型的应用对计算资源的需求大致在相同的范围内，因此，将每种类型的应用的性能所需要的计算资源固定分配好，避免计算资源被浪费，提高节点的吞吐量。
以下提出一种对计算节点中的计算资源进行配置得到资源表的方法，如图4所示，具体包括S102a-S102d：
S102a：管理节点确定计算节点的类型，以此来确定计算节点的计算资源所能分类的组合。
当计算节点的单核内存带宽小于第一带宽阈值，则该计算节点属于资源紧凑型节点。该种类型的节点的计算资源可以全部分配给A类资源，或者同时分配给A类资源和B类资源，或者同时分配给A类资源和C类资源。
当计算节点的单核内存带宽大于等于第一带宽阈值且小于第二带宽阈值，则该计算节点属于资源均衡型节点。该种类型的节点的资源可以全部分配给B类资源，或者同时分配给A类资源和C类资源。
当计算节点的单核内存带宽大于等于第二带宽阈值，则该计算节点属于资源充裕型节点。由于该种类型的节点计算资源较丰富，即使应用下发多个任务在该计算节点上，也不容易发生计算资源争抢的情况，因此可以不用对该种类型的节点的计算资源进行分类。
在一个示例中，若计算节点的CPU核数为32，内存带宽为204.8GB/s。该计算节点的单核内存带宽为6.4GB/s。则该计算节点属于资源均衡型节点。可以将该计算节点的计算资源全部分配给B类资源，或者，分配给A类资源和C类资源。
S102b：管理节点确定对计算节点的计算资源所能分类的组合后，确定每类资源所包括的CPU核数和内存带宽。
在一个示例中，当计算节点的计算资源分配给A类资源和C类资源。
A类资源所包括的CPU核数和内存带宽，以及C类资源所包括的CPU核数和内存带宽，是基于多个RA应用在CPU上运行时的平均单核内存带宽、多个RC应用在CPU上运行时的平均单核内存带宽、计算节点的内存带宽和计算节点的CPU核数确定的。
A类资源所包括的CPU核数＝计算节点的CPU核数-C类资源所包括的CPU核数。
具体的，A类资源所包括的CPU核数core1和内存带宽BW1，C类资源所包括的CPU核数core2和内存带宽BW2，多个RA应用在CPU上运行时的平均单核内存带宽bw1、多个RC应用在CPU上运行时的平均单核内存带宽bw2、计算节点的内存带宽BW和计算节点的CPU核数CORE之间满足如下公式：
core2＝(BW-CORE*bw1)/(bw2-bw1)；
core1＝CORE-core2；
BW1＝core1*bw1；
BW2＝core2*bw2。
以下以计算至少一个RA应用的平均内存带宽为例，提出两种计算至少一个RA应用的平均内存带宽的方法。
在一种可能的实现方式中，将至少一个RA应用在任意单个CPU或单个节点上运行，得到该至少一个RA应用在该单个CPU或单个节点上的平均内存带宽，用该至少一个RA应用的平均内存带宽除以运行该RA应用的CPU核数，得到至少一个RA应用的平均单核内存带宽。若有多个RA应用，则计算多个RA应用的平均单核内存带宽和的平均值，将该平均值作为A类资源的单核内存带宽。
示例性的，若单个CPU或者单个节点的CPU的核数为32核，有三个RA应用在该单个CPU或单个节点上运行后，分别得到的平均内存带宽为120GB/s、135GB/s和128GB/s，则三个RA应用的平均单核内存带宽分别为3.75GB/s、4.21GB/s和4GB/s。该三个RA应用的平均单核内存带宽的和的平均值为3.98GB/s。
在另一种可能的实现方式中，使用如Linux perf工具，intel vtune工具中的TOP-DOWN工具，计算至少一个RA应用的DRAM bound的百分比，通过公式：至少一个RA应用的平均内存带宽*(1/(1-DRAM bound的百分比))/CPU核数，得到至少一个RA应用的平均单核内存带宽。
由此可以将上述两种方法中计算得到的至少一个RA应用的平均单核内存带宽的值作为A类资源的单核内存带宽。
上述方法中在单个CPU或单个节点上执行多个RA应用，计算出多个RA应用的平均单核内存带宽，再取多个平均单核内存带宽的平均值作为A类资源的单核内存带宽，该方法算出来的A类资源的单核内存带宽的值更准确。
以下通过一个具体的示例来说明如何计算每类资源所包括的CPU核数和内存带宽。
在一个示例中，若计算节点的CPU核数为32，内存带宽为204.8GB/s。该计算节点的单核内存带宽为6.4GB/s。则该计算节点属于资源均衡型节点。可以将该计算节点的计算资源全部分配给B类资源，或者，分配给A类资源和C类资源。
若将该计算节点的计算资源全部分配给B类资源，则分配给该B类资源的CPU核数为32，内存带宽为204.8GB/s(单核内存带宽为6.4GB/s)。
若将该计算节点的计算资源分配给A类资源和C类资源，其中，基于上述提出的两种计算至少一个RA应用的平均内存带宽的方法，取A类资源的单核内存带宽为4GB/s，取C类资源的单核内存带宽为9GB/s。
则C类资源所包括的CPU核数＝(204.8-32*4)/(9-4)＝15.3个。
基于HPC集群并行计算的特点，一般的，每类资源的CPU核数取值为2的倍数。因此，若取15.3最接近2的倍数的值，则C类资源所包括的CPU核数为16个。对应地，A类资源所包括的CPU核数为16个。
上述示例是在预先设置了A类资源的单核内存带宽和C类资源的单核内存带宽后，计算出为A类资源和C类资源分配的CPU核数。若在不预设A类资源的单核内存带宽，将C类资源的单核内存带宽取值为9GB/s的情况下，依次计算C类资源取不同的CPU核数时，对应的A类资源的单核内存带宽的大小。可以得到如表1所示的组合关系。其中，表1包括“C类资源的CPU核数”、“A类资源的CPU核数”和“A类资源的单核内存带宽取值”。
表1
C类资源的CPU核数 A类资源的CPU核数 A类资源的单核内存带宽取值
4 28 6.03
6 26 5.80
8 24 5.53
10 22 5.22
12 20 4.84
16 16 3.80
18 14 3.06
20 12 2.07
从上述表1可以看出，当A类资源的CPU核数和C类资源的CPU核数分别为16核，C类资源的单核内存带宽取值为9GB/s时，A类资源的单核内存带宽取值为3.8GB/s最接近上述示例所取的4GB/s。
S102c：管理节点确定每类资源所包括的LLC Way数。
若将计算节点的计算资源全部分配给B类资源，则该B类资源所包括的LLC Way数为计算节点的LLC Way数。
若将计算节点的计算资源分配给A类资源和C类资源，则A类资源所包括的LLC Way数是基于A类资源所包括的CPU核数、至少一个RA应用的执行性能和计算节点的LLC Way数确定的。C类资源所包括的LLC Way数是基于A类资源所包括的LLC Way数和计算节点的LLCWay数确定的。
其中，上述执行性能是基于LLC Way数，执行至少一个RA应用得到的RA应用的性能。
在一种可能的实施方式中，A类资源所包括的LLC Way数可以通过S1-S4计算得到。
S1：管理节点确定A类资源的候选LLC Way数。
为A类资源的LLC Way数预设初始值作为A类资源的候选LLC Way数。
可以将计算节点的LLC Way数平均分配给A类资源和C类资源，以此确定A类资源的候选LLC Way数。
或者，按照A类资源和C类资源所包括的CPU核数的比例，将计算节点的LLC Way数按CPU核数的比例分配给A类资源和C类资源，以此确定A类资源的候选LLC Way数。
在一个示例中，计算节点的LLC Way数为12，为A类资源配置的CPU核数为16，为C类资源配置的CPU核数为16。若将计算节点的LLC Way数平均分配给A类资源和C类资源，则为A类资源分配的候选LLC Way数为6，为C类资源计算分配的候选LLC Way数为6。
在另一个示例中，计算节点的LLC Way数为12，为A类资源配置的CPU核数为16，为C类资源配置的CPU核数为16。若将计算节点的LLC Way数按CPU核数比例1：1分配给A类资源和C类资源，则为A类资源分配的候选LLC Way数为6，为C类资源分配的候选LLC Way数为6。
S2：管理节点基于A类资源的候选LLC Way数，依次减少或增加A类资源的候选LLCWay数，得到多个待选LLC Way数。
在一个示例中，若A类资源的候选LLC Way数为6，则依次减少或增加A类资源的候选LLC Way数后，得到的多个待选LLC Way数分别为5、4、3、2和1，或者7、8、9、10、11、12。
S3：管理节点基于多个待选LLC Way数，分别执行至少一个RA应用，得到多个执行性能。
针对每个待选LLC Way数，管理节点分别执行一次至少一个RA应用，得到至少一个RA应用的执行性能。
在一个示例中，A类资源所包括的CPU核数为16，单核内存带宽为3.8GB/s，候选LLCWay数为6。在候选LLC Way数为6的基础上依次减少或增加候选LLC Way数，得到多个待选LLC Way数，分别执行两个RA应用如应用1和应用2，得到应用1和应用2在不同待选LLC Way数时的执行性能。如表2所示，表2示出两个RA应用的执行性能。表2包括“RA应用”、“A类资源所包括的CPU核数”、“A类资源的单核内存带宽”、“A类资源的待选LLC Way数”和“执行性能”。
表2
/>
S4：管理节点从多个执行性能中选取目标执行性能对应的待选LLC Way数，配置为A类资源所包括的LLC Way数。
其中，目标执行性能是多个执行性能中性能下降达到第一预设值之前的至少一个执行性能，或者，是多个执行性能中性能上升小于第二预设值之前的至少一个执行性能。
在一种可能的实现方式中，如果第一预设值为1％，第二预设值为1/管理节点的LLC Way数。从表2所示的两个RA应用执行性能中，选出当减少LLC Way数时执行性能下降达到1％之前的至少一个执行性能，对应表2中“应用1”的待选LLC Way数为4时的执行性能，和，表2中“应用2”的待选LLC Way数为3时的执行性能。
同时，选出增加LLC Way数时执行性能上升小于1/管理节点的LLC Way数的值，对应表2中“应用1”待选LLC Way数为8时的执行性能，和，表2中“应用2”待选LLC Way数为9时的执行性能。
从“应用1”中选出的待选LLC Way数在4～8之间，从“应用2”中选出的待选LLC Way数在3～9之间。从上述两个应用的待选LLC Way数的交集中选出所需要的LLC Way数，即从4～8中选取部分或全部作为A类资源的LLC Way数。一般的，为了提高管理节点的吞吐量，可以适当选取多个LLC Way数作为A类资源的LLC Way数。当然，由于CPU LLC Way数受CPU LLC服务质量(quality of service，QoS)数量限制，因此，选取的LLC Way数的数量不能超过QoS数量。
例如，若CPU LLC QoS数量为12，则为A类资源、B类资源和C类资源选取的LLC Way数的种类之和不能超过12种。
基于上述为A类资源设置的LLC Way数，对应的确定为C类资源设置的LLC Way数。
具体的，C类资源所包括的LLC Way数等于计算节点的LLC Way数减去A类资源所包括的LLC Way数。
例如，当A类资源所包括的LLC Way数为8，则C类资源所包括的LLC Way数等于管理节点的LLC Way数12减去A类资源所包括的LLC Way数8，得到C类资源所包括的LLC Way数为4。
综上所述，以下示例通过表3示出A类资源、B类资源和C类资源所包括的CPU核数、内存带宽和LLC Way数的几种资源组合类型。
在一个示例中，若计算节点为2路服务器，每路服务器的CPU核数为32，内存带宽为204.8GB/s，CPU LLC QoS数量为7，LLC Way数为12。通过上述S102a-S102c方法得到如表3所示的资源组合。表3包括“资源类型”、“CPU核数范围”、“单核内存带宽”和“LLC Way数”。其中，“CPU核数范围”、“单核内存带宽”和“LLC Way数”是每行“资源类型”所包括的具体计算资源值。
表3
资源类型 CPU核数范围 单核内存带宽 LLC Way数
B 0-63 6.3 12way/CPU
C1 16-31，48-63 9 4way/CPU
C2 16-31，48-63 9 6way/CPU
C3 16-31，48-63 9 8way/CPU
A1 0-15，32-47 3.8 8way/CPU
A2 0-15，32-47 3.8 6way/CPU
A3 0-15，32-47 3.8 4way/CPU
上述表3中B为B类资源，C1-C3为三种C类资源，A1-A3为三种A类资源。由表3可以看出每种A类资源或C类资源中，CPU核数范围与单核内存带宽相同，LLC Way数不相同。每一种C类资源有对应互补的A类资源。该设置方法是由于在CPU核数与单核内存带宽相同的情况下，不同的LLC Way数对同一种应用的执行性能有所不同，但是，在性能满足一定范围的条件下，选取其中几种LLC Way数作为资源配置的一种方式，既可以满足性能要求，也可以在一定情况下提高管理节点的吞吐量。
另外，上述表3所示的资源类型可以看出，当B类资源被使用后，管理节点将无法分配A类资源和C类资源。当A1类资源被使用后，只有与A1类资源互补的C1类资源可以被继续分配。当A2类资源被使用后，则C2类资源或C3类资源可以继续被分配。当A3类资源被使用后，则C1类资源、C2类资源或C3类资源可以继续被分配。由此可以看出，上述资源之间存在约束，管理节点在分配计算资源时需要基于未分配的计算资源来算出当前可以分配的计算资源。
S102d：管理节点建立应用的类型与计算资源的类型对应关系，得到资源表。
在一个示例中，所述资源表包括所述计算资源类型、CPU核数范围、单核内存带宽以及LLC Way数的对应关系，管理节点将表3配置的计算资源的类型与应用的类型相对应，得到表4所示的资源表。
表4
可选的，管理节点得到上述资源表后，将资源表配置到管理节点的调度器中。
管理节点在调度器的资源调度插件中配置资源表，包括预设每类计算资源所包括的CPU核数、内存带宽和LLC Way数。
基于表4中每类计算资源的单核内存带宽和CPU核数，可以得到每类资源的内存带宽。在资源调度插件中为A类资源、B类资源和C类资源配置内存带宽，更有利于执行应用下发的任务时分配内存带宽资源。
在一个示例中，通过slurm调度器的GRES机制配置表4所示的资源表后，得到如下配置结果：
Name＝QoS Type＝B COREs＝0-63MEMCOS＝0LLCCOS＝1
Name＝QoS Type＝C1 COREs＝0-15，32-47MEMCOS＝1LLCCOS＝2
Name＝QoS Type＝C2 COREs＝0-15，32-47MEMCOS＝1LLCCOS＝3
Name＝QoS Type＝C3 COREs＝0-15，32-47MEMCOS＝1LLCCOS＝4
Name＝QoS Type＝A1 COREs＝16-31，48-63MEMCOS＝2LLCCOS＝5
Name＝QoS Type＝A2 COREs＝16-31，48-63MEMCOS＝2LLCCOS＝6
Name＝QoS Type＝A3 COREs＝16-31，48-63MEMCOS＝2LLCCOS＝7
其中，Name为自定义的名称，Type表示计算资源类型，COREs表示可用的CPU核，MEMCOS＝0表示每16个CPU核所能使用的内存带宽为204.8GB/s(单核内存带宽6.4GB/s)，MEMCOS＝1表示每16个CPU核所能使用的内存带宽为144GB/s(单核内存带宽9GB/s)，MEMCOS＝2表示每16个CPU核所能使用的内存带宽为60.8GB/s(单核内存带宽3.8GB/s)。LLCCOS＝1表示COREs＝0-15,32-47对应的CPU核所能使用的LLC Way数为24，LLCCOS＝2表示COREs＝0-15,32-47对应的CPU核所能使用的LLC Way数为8，LLCCOS＝3表示COREs＝0-15,32-47对应的CPU核所能使用的LLC Way数为12，LLCCOS＝4表示COREs＝0-15,32-47对应的CPU核所能使用的LLC Way数为16，LLCCOS＝5表示COREs＝16-31,48-63对应的CPU核所能使用的LLCWay数为16，LLCCOS＝6表示COREs＝16-31,48-63对应的CPU核所能使用的LLC Way数为12，LLCCOS＝7表示COREs＝16-31,48-63对应的CPU核所能使用的LLC Way数为8。
上述示例中的方法基于传统技术中的资源调度插件实现资源表配置，不需要改变硬件结构，操作简单，容易实现。
S103：管理节点在接收目标应用下发的任务后，基于目标应用所属的类型和资源表，为目标应用下发的任务分配计算资源。
可选的，管理节点在接收目标应用下发的任务后，将任务提交到调度器，调度器基于目标应用所属的类型和资源表，将目标应用下发的任务提交到至少一个计算节点的目标任务队列，以使得至少一个计算节点为目标应用下发的任务分配目标任务队列所关联的计算资源。
上述目标任务队列关联了目标应用的类型和目标应用的类型对应的计算资源类型。
上述可选的方法执行前，计算节点为每个计算资源类型设置对应的任务队列。
每个计算资源类型对应的任务队列关联了每个计算资源类型和每个计算资源类型对应的应用的类型。
在一种可能的实现方式中，如S103所示的在调度器的GRES插件中配置的表4所示的资源表，计算节点为每类计算资源设置对应的任务队列，则共设置了7个任务队列，分别关联B、A1、A2、A3、C1、C2和C3类资源，且与B类资源对应的任务队列关联了RB应用，与A1、A2或A3类资源对应的任务队列关联了RA应用，与C1、C2或C3类资源对应的任务队列关联了RC应用。
在一个示例中，目标应用为RA应用，目标任务队列关联了RA应用和A类资源，例如A1，当目标应用下发任务，此时管理节点将目标应用下发的任务提交到计算节点的目标任务队列，计算节点为目标应用下发的任务分配A1资源。
该步骤在计算节点设置了任务队列的基础上，管理节点在进行任务调度时，直接基于应用类型将应用下发的任务提交到与该应用类型关联的任务队列，以使得计算节点执行每个任务时使用固定分配的计算资源，避免不同的任务发生资源争抢。
本申请实施例提出的一种任务调度方法中，管理节点将应用分为多种类型，并为每种类型的应用配置对应类型的计算资源，当有应用下发任务时，管理节点基于应用的类型，为该应用下发的任务分配对应类型的计算资源。可以理解的是，由于不同应用对计算资源的敏感程度不同，因此可以将对计算资源的敏感程度不同的应用分为不同的类别，并基于应用的类别，为该类别的应用配置满足该类别应用性能的计算资源，以此来解决传统技术中因未考虑应用性能导致资源浪费的问题，提高了资源利用率、集群吞吐量和性能。
上述主要从方法的角度对本申请实施例提供的方案进行了介绍。为了实现上述功能，其包含了执行各个功能相应的硬件结构和/或软件模块。本领域技术目标应该很容易意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术目标可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请实施例的范围。
本申请实施例还提供一种管理节点200。如图5所示，为本申请实施例提供的一种管理节点200的结构示意图。
其中，管理节点200包括：获取单元201，用于获取多个应用的类型；其中，不同类型的应用对计算资源的敏感程度不同；资源配置单元202，用于基于多个应用的类型，对计算节点中的计算资源进行配置，得到资源表；其中，资源表中包括多个计算资源类型，计算资源类型与应用的类型存在对应关系，多个计算资源类型之间存在资源约束，计算资源类型由应用在不同计算资源下的性能测试结果确定；任务调度单元203，用于在管理节点接收目标应用下发的任务后，基于目标应用所属的类型和资源表，为目标应用下发的任务分配计算资源。例如，如图2所示，获取单元201用于方法实施例中的S101，资源配置单元202用于方法实施例中的S102，任务调度单元203用于方法实施例中的S103。
可选的，至少一个计算节点中设置了每个计算资源类型对应的任务队列；每个计算资源类型对应的任务队列关联了每个计算资源类型和每个计算资源类型对应的应用的类型；任务调度单元203具体用于，将目标应用下发的任务提交到至少一个计算节点的目标任务队列，以使得至少一个计算节点为目标应用下发的任务分配目标任务队列所关联的计算资源；目标任务队列关联了目标应用的类型和目标应用的类型对应的计算资源类型。
可选的，计算资源包括内存带宽；多个应用的类型包括：第一类应用、第二类应用和第三类应用；其中，第一类应用对内存带宽的敏感程度小于第一阈值；第二类应用对内存带宽的敏感程度大于或等于第一阈值，且小于第二阈值；第三类应用对内存带宽的敏感程度大于或等于第二阈值；第一阈值小于第二阈值；多个计算资源类型包括：第一类资源、第二类资源和第三类资源；其中，第一类资源的单核内存带宽小于第一带宽阈值；第二类资源的单核内存带宽大于等于第一带宽阈值，且小于第二带宽阈值；第三类资源的单核内存带宽大于等于第二带宽阈值；第一带宽阈值小于第二带宽阈值；第一类应用对应第一类资源；第二类应用对应第二类资源；第三类应用对应第三类资源。
可选的，计算资源还包括CPU核数；第一类资源所包括的CPU核数和内存带宽，以及第三类资源所包括的CPU核数和内存带宽，是基于多个第一类应用在CPU上运行时的平均单核内存带宽、多个第三类应用在CPU上运行时的平均单核内存带宽、计算节点的内存带宽和计算节点的CPU核数确定的。
可选的，第一类资源所包括的CPU核数core1和内存带宽BW1，第三类资源所包括的CPU核数core2和内存带宽BW2，多个第一类应用在CPU上运行时的平均单核内存带宽bw1、多个第三类应用在CPU上运行时的平均单核内存带宽bw2、计算节点的内存带宽BW和计算节点的CPU核数CORE之间满足如下公式：core2＝(BW-CORE*bw1)/(bw2-bw1)；core1＝CORE-core2；BW1＝core1*bw1；BW2＝core2*bw2。
可选的，计算资源还包括LLC Way数；第一类资源所包括的LLC Way数是基于第一类资源所包括的CPU核数、至少一个第一类应用的执行性能和计算节点的LLC Way数确定的；其中，执行性能是基于LLC Way数，执行至少一个第一类应用得到的第一类应用的性能；第三类资源所包括的LLC Way数是基于第一类资源所包括的LLC Way数和计算节点的LLCWay数确定的。
可选的，资源配置单元202具体用于，获取第一类资源的候选LLC Way数，并依次减少或增加第一类资源的候选LLC Way数，得到多个待选LLC Way数；基于多个待选LLC Way数，分别执行至少一个第一类应用，得到多个执行性能；将多个执行性能中的目标执行性能对应的待选LLC Way数，配置为第一类资源所包括的LLC Way数；其中，目标执行性能是多个执行性能中性能下降达到第一预设值之前的至少一个执行性能，或者，是多个执行性能中性能上升小于第二预设值之前的至少一个执行性能。例如，资源配置单元202用于方法实施例中的S102c。
当然，本申请实施例提供的管理节点200包括但不限于上述模块。
图6是本申请实施例提供的服务器300的结构示意图，例如图1所示的管理节点。如图6所示，该服务器300包括处理器301、存储器302和网络接口303。
其中，处理器301包括一个或多个CPU。该CPU可以为单核CPU(single-CPU)或多核CPU(multi-CPU)。
存储器302包括但不限于是随机存取存储器(random access memory，RAM)、只读存储器(read-only memory，ROM)、可擦除可编程只读存储器(erasable programmableread-only memory，EPROM)、快闪存储器、或光存储器等。
可选地，处理器301通过读取存储器302中保存的指令实现本申请实施例提供的任务调度方法，或者，处理器301通过内部存储的指令实现本申请实施例提供的任务调度方法。在处理器301通过读取存储器302中保存的指令实现上述实施例中的方法的情况下，存储器302中保存实现本申请实施例提供的任务调度方法的指令。
网络接口303，包含发送器和接收器的一类装置，用于与其他设备或通信网络通信，可以是有线接口(端口)，例如光纤分布式数据接口(fiber distributed datainterface，FDDI)、千兆以太网接口(gigabit ethernet，GE)。或者，网络接口303是无线接口。应理解，网络接口303包括多个物理端口，网络接口303用于通信等。
可选地，服务器300还包括总线304，上述处理器301、存储器302、网络接口303通常通过总线304相互连接，或采用其他方式相互连接。
在实际实现时，获取单元201、资源配置单元202和任务调度单元203可以由处理器调用存储器中的计算机程序代码来实现。其具体的执行过程可参考上述方法部分的描述，这里不再赘述。
本申请另一实施例还提供一种服务器，包括存储器和处理器。存储器和处理器耦合；存储器用于存储计算机程序代码，计算机程序代码包括计算机指令。其中，当处理器执行该计算机指令时，使得该服务器执行上述方法实施例所示的任务调度方法的各个步骤。
本申请另一实施例还提供一种计算机可读存储介质，该计算机可读存储介质中存储有计算机指令，当计算机指令在服务器上运行时，使得服务器执行上述方法实施例所示的任务调度方法流程中服务器执行的各个步骤。
本申请另一实施例还提供一种芯片系统，该芯片系统应用于服务器。该芯片系统包括一个或多个接口电路，以及一个或多个处理器。接口电路和处理器通过线路互联。接口电路用于从服务器的存储器接收信号，并向处理器发送信号，信号包括存储器中存储的计算机指令。当服务器处理器执行计算机指令时，服务器执行上述方法实施例所示的任务调度方法流程中服务器执行的各个步骤。
在本申请另一实施例中还提供一种计算机程序产品，该计算机程序产品包括计算机指令，当计算机指令在服务器上运行时，使得服务器执行上述方法实施例所示的任务调度方法流程中服务器执行的各个步骤。
上述实施例可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件程序实现时，上述实施例可以全部或部分地以计算机程序产品的形式来实现。该计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行计算机执行指令时，全部或部分地产生按照本申请实施例的流程或功能。计算机可以是通用计算机、专用计算机、计算机网络、服务器或者其他可编程装置。计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，计算机指令可以从一个网站站点、计算机、服务器或者数据中心通过有线(例如同轴电缆、光纤、数字用户线(digital subscriber line，DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可以用介质集成的服务器、数据中心等数据存储设备。可用介质可以是磁性介质(例如，软盘、硬盘、磁带)，光介质(例如，DVD)、或者半导体介质(例如固态硬盘(solid state disk，SSD))等。
以上所述，仅为本申请的具体实施方式。熟悉本技术领域的技术人员根据本申请提供的具体实施方式，可想到变化或替换，都应涵盖在本申请的保护范围之内。

Claims (10)

1.一种任务调度方法，其特征在于，应用于管理节点，所述管理节点与至少一个计算节点连接，所述方法包括：
获取多个应用的类型；其中，不同类型的应用对计算资源的敏感程度不同；
基于所述多个应用的类型，对所述计算节点中的计算资源进行配置，得到资源表；其中，所述资源表中包括多个计算资源类型，所述计算资源类型与所述应用的类型存在对应关系，所述多个计算资源类型之间存在资源约束，所述计算资源类型由所述应用在不同计算资源下的性能测试结果确定；
在所述管理节点接收目标应用下发的任务后，基于所述目标应用所属的类型和所述资源表，为所述目标应用下发的任务分配计算资源。
2.根据权利要求1所述的方法，其特征在于，所述至少一个计算节点中设置了每个计算资源类型对应的任务队列；所述每个计算资源类型对应的任务队列关联了所述每个计算资源类型和所述每个计算资源类型对应的所述应用的类型；
所述为所述目标应用下发的任务分配计算资源，包括：
将所述目标应用下发的任务提交到所述至少一个计算节点的目标任务队列，以使得所述至少一个计算节点为所述目标应用下发的任务分配所述目标任务队列所关联的计算资源；所述目标任务队列关联了所述目标应用的类型和所述目标应用的类型对应的计算资源类型。
3.根据权利要求1或2所述的方法，其特征在于，所述资源表包括所述计算资源类型、CPU核数范围、单核内存带宽以及LLC Way数的对应关系。
4.根据权利要求1或2所述的方法，其特征在于，所述计算资源包括内存带宽；
所述多个应用的类型包括：第一类应用、第二类应用和第三类应用；其中，所述第一类应用对所述内存带宽的敏感程度小于第一阈值；所述第二类应用对所述内存带宽的敏感程度大于或等于所述第一阈值，且小于第二阈值；所述第三类应用对所述内存带宽的敏感程度大于或等于所述第二阈值；所述第一阈值小于所述第二阈值；
所述多个计算资源类型包括：第一类资源、第二类资源和第三类资源；其中，所述第一类资源的单核内存带宽小于第一带宽阈值；所述第二类资源的单核内存带宽大于等于第一带宽阈值，且小于第二带宽阈值；所述第三类资源的单核内存带宽大于等于第二带宽阈值；所述第一带宽阈值小于所述第二带宽阈值；
所述第一类应用对应所述第一类资源；所述第二类应用对应所述第二类资源；所述第三类应用对应所述第三类资源。
5.根据权利要求4所述的方法，其特征在于，所述计算资源还包括CPU核数；
所述第一类资源所包括的CPU核数和内存带宽，以及所述第三类资源所包括的CPU核数和内存带宽，是基于多个第一类应用在CPU上运行时的平均单核内存带宽、多个第三类应用在CPU上运行时的平均单核内存带宽、所述计算节点的内存带宽和所述计算节点的CPU核数确定的。
6.根据权利要求5所述的方法，其特征在于，所述第一类资源所包括的CPU核数core1和内存带宽BW1，所述第三类资源所包括的CPU核数core2和内存带宽BW2，多个第一类应用在CPU上运行时的平均单核内存带宽bw1、多个第三类应用在CPU上运行时的平均单核内存带宽bw2、所述计算节点的内存带宽BW和所述计算节点的CPU核数CORE之间满足如下公式：
core2＝(BW-CORE*bw1)/(bw2-bw1)；
core1＝CORE-core2；
BW1＝core1*bw1；
BW2＝core2*bw2。
7.根据权利要求5或6所述的方法，其特征在于，所述计算资源还包括末级缓存通道LLCWay数；
所述第一类资源所包括的LLC Way数是基于所述第一类资源所包括的CPU核数、至少一个第一类应用的执行性能和所述计算节点的LLC Way数确定的；其中，所述执行性能是基于所述LLC Way数，执行所述至少一个第一类应用得到的所述第一类应用的性能；
所述第三类资源所包括的LLC Way数是基于所述第一类资源所包括的LLC Way数和所述计算节点的LLC Way数确定的。
8.根据权利要求7所述的方法，其特征在于，所述对所述计算节点中的计算资源进行配置，包括：
获取所述第一类资源的候选LLC Way数，并依次减少或增加所述第一类资源的候选LLCWay数，得到多个待选LLC Way数；
基于所述多个待选LLC Way数，分别执行所述至少一个第一类应用，得到多个执行性能；
将所述多个执行性能中的目标执行性能对应的待选LLC Way数，配置为所述第一类资源所包括的LLC Way数；其中，所述目标执行性能是所述多个执行性能中性能下降达到第一预设值之前的至少一个执行性能，或者，是所述多个执行性能中性能上升小于第二预设值之前的至少一个执行性能。
9.一种服务器，其特征在于，包括存储器和处理器；所述存储器和所述处理器耦合；所述存储器用于存储计算机程序代码，所述计算机程序代码包括计算机指令；其中，当所述服务器执行所述计算机指令时，使得所述服务器执行如权利要求1-8中任意一项所述的任务调度方法。
10.一种服务器集群，其特征在于，包括管理节点和多个计算节点；
所述管理节点用于获取多个应用的类型；其中，不同类型的应用对计算资源的敏感程度不同；基于所述多个应用的类型，对所述计算节点中的计算资源进行配置，得到资源表；其中，所述资源表中包括多个计算资源类型，所述计算资源类型与所述应用的类型存在对应关系，所述多个计算资源类型之间存在资源约束，所述计算资源类型由所述应用在不同计算资源下的性能测试结果确定；在所述管理节点接收目标应用下发的任务后，基于所述目标应用所属的类型和所述资源表，为所述目标应用下发的任务分配计算资源；
所述计算节点用于，使用所述管理节点为所述目标应用下发的任务分配的计算资源，执行所述目标应用下发的任务。
CN202310442976.3A 2023-04-23 2023-04-23 一种任务调度方法、服务器及服务器集群 Pending CN116643875A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202310442976.3A CN116643875A (zh) 2023-04-23 2023-04-23 一种任务调度方法、服务器及服务器集群

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202310442976.3A CN116643875A (zh) 2023-04-23 2023-04-23 一种任务调度方法、服务器及服务器集群

Publications (1)

Publication Number Publication Date
CN116643875A true CN116643875A (zh) 2023-08-25

Family

ID=87623713

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202310442976.3A Pending CN116643875A (zh) 2023-04-23 2023-04-23 一种任务调度方法、服务器及服务器集群

Country Status (1)

Country Link
CN (1) CN116643875A (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117170848A (zh) * 2023-09-11 2023-12-05 赛尔新技术（北京）有限公司 一种资源调度方法及装置

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117170848A (zh) * 2023-09-11 2023-12-05 赛尔新技术（北京）有限公司 一种资源调度方法及装置

Similar Documents

Publication Publication Date Title
CN109218355B (zh) 负载均衡引擎，客户端，分布式计算系统以及负载均衡方法
CN106776005B (zh) 一种面向容器化应用的资源管理系统及方法
US9092266B2 (en) Scalable scheduling for distributed data processing
WO2018177012A1 (zh) 一种控制带宽的方法、装置和设备
WO2021136137A1 (zh) 一种资源调度方法、装置及相关设备
JP6290462B2 (ja) ネットワーク・アクセス可能なブロック・ストレージのための協調アドミッション制御
US8918566B2 (en) System and methods for allocating shared storage resources
US9201690B2 (en) Resource aware scheduling in a distributed computing environment
CN107534583B (zh) 在管理节点中实现的方法和相关装置
US20120317578A1 (en) Scheduling Execution of Complementary Jobs Based on Resource Usage
US20150277772A1 (en) Global Memory Sharing Method and Apparatus, and Communications System
US10848440B2 (en) Systems and methods for allocating bandwidth across a cluster of accelerators
US8898674B2 (en) Memory databus utilization management system and computer program product
US7460558B2 (en) System and method for connection capacity reassignment in a multi-tier data processing system network
WO2014022395A1 (en) Priority driven channel allocation for packet transferring
US20220156115A1 (en) Resource Allocation Method And Resource Borrowing Method
WO2021036330A1 (zh) 备份处理方法及服务器
US20070248007A1 (en) Broadband access network capacity management
WO2023125493A1 (zh) 资源管理方法、装置及资源管理平台
CN116643875A (zh) 一种任务调度方法、服务器及服务器集群
WO2016082320A1 (zh) 混合异构主机系统及资源配置方法、任务调度方法
WO2018196865A1 (en) Guided optimistic resource scheduling
CN116089051A (zh) 一种任务分配方法、装置及系统
WO2020108337A1 (zh) 一种cpu资源调度方法及电子设备
CN111131447A (zh) 一种基于中介节点任务分配的负载均衡方法

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