CN110597639A

CN110597639A - Cpu分配控制方法、装置、服务器及存储介质

Info

Publication number: CN110597639A
Application number: CN201910900833.6A
Authority: CN
Inventors: 和利冰
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2019-09-23
Filing date: 2019-09-23
Publication date: 2019-12-20
Anticipated expiration: 2039-09-23
Also published as: CN110597639B

Abstract

本申请公开了一种CPU分配控制方法、装置、服务器及存储介质，属于资源调度领域。所述方法包括：获取目标任务的CPU需求量；根据CPU需求量确定目标Node，目标Node用于执行目标任务，且目标Node的CPU可分配量大于CPU需求量；根据目标Node中CPU的CPU状态，为目标任务分配CPU，CPU状态包括超线程状态和非超线程状态；目标任务在执行状态下，根据服务器的当前CPU使用率，对服务器中的超卖CPU进行超卖控制。本申请提供的方法，实现了基于CPU状态对目标任务进行CPU适应性分配，有助于提高目标任务的执行效率；此外引入了超卖机制，对超卖CPU进行控制，进一步提高了服务器的CPU使用率。

Description

CPU分配控制方法、装置、服务器及存储介质

技术领域

本申请实施例涉及资源调度领域，特别涉及一种CPU分配控制方法、装置、服务器及存储介质。

背景技术

分布式调度系统是面向多用户、多任务的，分布式调度系统主要包括两个方面：任务调度和资源调度。

其中，资源调度主要解决的问题是如何将封装的CPU、内存资源在多个任务之间调度。

对于多个在线任务与离线任务同时部署在同一台服务器上的情况，相关CPU分配方案并未考虑基于该情况的多任务混合部署，也未考虑在系统开启超线程时，不同的CPU分配情况对多任务混合部署带来的影响，从而对提升CPU使用率和降低数据中心运营成本带来困难。

发明内容

本申请实施例提供了一种CPU分配控制方法、装置、服务器及存储介质，能够解决多任务混合部署下CPU使用率较低的问题。所述技术方案如下：

一方面，提供了一种CPU分配控制方法，所述方法用于服务器，所述服务器中设置至少两个节点Node，所述方法包括：

获取目标任务的CPU需求量；

根据所述CPU需求量确定目标Node，所述目标Node用于执行所述目标任务，且所述目标Node的CPU可分配量大于所述CPU需求量；

根据所述目标Node中CPU的CPU状态，为所述目标任务分配CPU，所述CPU状态包括超线程状态和非超线程状态；

所述目标任务在执行状态下，根据所述服务器的当前CPU使用率，对所述服务器中的超卖CPU进行超卖控制，所述超卖CPU是对所述服务器中的CPU进行超额分配时虚拟出的CPU。

另一方面，提供了一种CPU分配和自适应控制装置，所述装置用于服务器，所述服务器中设置至少两个节点Node，所述装置包括：

需求量获取模块，用于获取目标任务的CPU需求量；

节点确定模块，用于根据所述CPU需求量确定目标Node，所述目标Node用于执行所述目标任务，且所述目标Node的CPU可分配量大于所述CPU需求量；

CPU分配模块，用于根据所述目标Node中CPU的CPU状态，为所述目标任务分配CPU，所述CPU状态包括超线程状态和非超线程状态；

CPU控制模块，用于所述目标任务在执行状态下，根据所述服务器的当前CPU使用率，对所述服务器中的超卖CPU进行超卖控制，所述超卖CPU是对所述服务器中的CPU进行超额分配时虚拟出的CPU。

另一方面，提供了一种服务器，所述服务器包括处理器和存储器；所述存储器存储有至少一条指令，所述至少一条指令用于被所述处理器执行以实现如上述方面所述的CPU分配控制方法。

另一方面，提供了一种计算机可读存储介质，所述存储介质存储有至少一条指令，所述至少一条指令用于被处理器执行以实现如上述方面所述的CPU分配控制方法。

本申请实施例中，服务器获取目标任务的CPU需求量，根据CPU需求量确定出用于执行目标任务的目标Node，确保目标Node能够满足目标任务对CPU的需求；同时，服务器根据目标Node中CPU的超线程或非超线程状态来为目标任务分配CPU，实现了基于CPU状态对目标任务进行CPU适应性分配，有助于提高目标任务的执行效率；此外，服务器引入了超卖机制，在CPU进行超卖的过程中对超卖CPU进行控制，进一步提高了服务器中的CPU使用率。

附图说明

图1是本申请一个示意性实施例提供的实施环境的示意图；

图2是本申请另一个示意性实施例提供的实施环境的示意图；

图3示出了本申请一个示例性实施例提供的基于Numa架构下的CPU结构拓扑图；

图4示出了本申请一个示例性实施例提供的CPU分配控制方法的流程图；

图5示出了本申请一个示例性实施例提供的目标任务分配过程的示意图；

图6示出了本申请另一个示例性实施例提供的CPU分配控制方法的流程图；

图7示出了本申请另一个示例性实施例提供的基于Numa架构下的CPU结构拓扑图；

图8示出了本申请另一个示例性实施例提供的CPU分配控制方法的流程图；

图9示出了本申请另一个示例性实施例提供的CPU分配控制方法的流程图；

图10示出了本申请一个示例性实施例提供的服务器对超卖CPU进行超卖控制过程的示意图；

图11为下调策略下超卖CPU的RealOversoldQuota数值变化图；

图12为上调策略下超卖CPU的RealOversoldQuota数值变化图；

图13示出了本申请一个示例性实施例提供的CPU分配控制装置的结构框图；

图14示出了本申请一个示例性实施例提供的服务器的结构示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明实施方式作进一步地详细描述。

在本文中提及的“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。

请参考图1，其示出了本申请一个实施例提供的实施环境的示意图。该实施环境可以包括：终端110、集群管理器(ResourceManager)120和包含有节点管理器(NodeManager)131的服务器130。

终端110可以是个人计算机、手机、平板电脑等电子设备，且该电子设备通过无线或有线的方式向服务器130请求分配完成终端110任务的CPU资源。本申请实施例中，终端110向集群管理器120提交待处理任务(如Job1和Job2)，集群管理器120为待处理任务选择合适的服务器130去运行，最终待处理任务由被选择的服务器130上的节点管理器131运行起来，从而被选择的节点管理器131为各个待处理任务分配CPU，并监控CPU和内存的使用情况。

其中，集群管理器120分布于如图2所示的分布式资源调度系统架构中，节点管理器131与应用程序的应用程序主机(Application Master)231和集群管理器120进行交互，即保持数据通信。其中，每一个待处理任务都对应有一个应用程序主机231，且应用程序主机231存储有对应待处理任务CPU资源需求量。当集群管理器120从终端110获取待处理的任务之后，集群管理器120与该待处理任务对应的应用程序主机231进行CPU分配资源的协商，以将满足待处理任务CPU资源需求的节点管理器131分配给待处理任务，并将可分配的节点管理器131的信息传输给应用程序主机231，接着，应用程序主机231启动对应的节点管理器131来执行相应的待处理任务。

此外，在本申请实施例所提供的集群(Cluster)230内部，还包括有应用程序界面服务器(API Server)232、查询服务器(Query Server)233、和执行器(Executor)234。其中，应用程序界面服务器232用于提供资源管理器120的API接口(包括认证授权、数据校验以及集群状态变更)，用于提供其他模块之间的数据交互和通信的枢纽(其他模块通过应用程序界面服务器232查询或修改数据)，同时，应用程序界面服务器232是资源配额控制的入口，拥有完备的集群安全机制；查询服务器233用于显示关于服务器定义的信息，包括查询指定名称的服务器以及指定服务器信息的显示方式；执行器234为节点管理器131内用于执行任务的一个进程，当在分布式资源调度系统完成目标任务的资源分配后，资源管理器120为各个任务分配并启动执行器234，每一个执行器234运行对应的任务，并负责将数据存储于内存或磁盘上。

如图2所示，分布式资源调度系统架构内还包含有虚线框210内用于分布式资源调度系统界面设计的模块，具体包括有客户端工具(ClientTools)211、网络产品界面设计(WebUI)212和运维系统213。其中，客户端工具211用于为分布式资源调度系统界面设计提供界面交互元素；网络产品界面设计212用于设计分布式资源调度系统界面的页面框架，让系统界面的结构更加清晰；运维系统213用于保障分布式资源调度系统的正常运行，运维有运行和维护两层含义，对于复杂的分布式资源调度系统其维护难度较大，通过运维系统213尽可能减少运行过程的损失、预防运行过程中的各种错误以及尽可能地去修复各种突发情况。

在一种可能的实施方式中，服务器130可以是区块链节点服务器。区块链是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。区块链(Blockchain)，本质上是一个去中心化的数据库，是一串使用密码学方法相关联产生的数据块，每一个数据块中包含了一批次网络交易的信息，用于验证其信息的有效性(防伪)和生成下一个区块。区块链可以包括区块链底层平台、平台产品服务层以及应用服务层。

区块链底层平台可以包括用户管理、基础服务、智能合约以及运营监控等处理模块。其中，用户管理模块负责所有区块链参与者的身份信息管理，包括维护公私钥生成(账户管理)、密钥管理以及用户真实身份和区块链地址对应关系维护(权限管理)等，并且在授权的情况下，监管和审计某些真实身份的交易情况，提供风险控制的规则配置(风控审计)；基础服务模块部署在所有区块链节点设备上，用来验证业务请求的有效性，并对有效请求完成共识后记录到存储上，对于一个新的业务请求，基础服务先对接口适配解析和鉴权处理(接口适配)，然后通过共识算法将业务信息加密(共识管理)，在加密之后完整一致的传输至共享账本上(网络通信)，并进行记录存储；智能合约模块负责合约的注册发行以及合约触发和合约执行，开发人员可以通过某种编程语言定义合约逻辑，发布到区块链上(合约注册)，根据合约条款的逻辑，调用密钥或者其它的事件触发执行，完成合约逻辑，同时还提供对合约升级注销的功能；运营监控模块主要负责产品发布过程中的部署、配置的修改、合约设置、云适配以及产品运行中的实时状态的可视化输出，例如：告警、监控网络情况、监控节点设备健康状态等。

平台产品服务层提供典型应用的基本能力和实现框架，开发人员可以基于这些基本能力，叠加业务的特性，完成业务逻辑的区块链实现。应用服务层提供基于区块链方案的应用服务给业务参与方进行使用。

此外，无论是本申请实施例所提供的分布式资源调度系统下的集群结构还是用于实现其他功能的集群结构，如图2所示，YardGate 220与名称服务器(NameSever)221是各个集群共有的模块。其中，YardGate 220是集群230的统一接入层；名称服务器221用于标记被指定为区域权威服务器的服务器，通过在名称服务器221的资源记录中列出该服务器，其他服务器就认为该服务器是该区域的权威服务器，即在名称服务器221的资源记录中指定的任何服务器都被其他服务器当作权威的来源，并且能肯定应答区域内所含名称的查询。本申请所提供的技术方案适用于所有运行Linux操作的数据中心服务器，本申请所提供的技术方案运行在如图2所示的分布式资源调度系统中的节点管理器131上。该节点管理器131是运行在数据中心每一台服务器上的一个程序，本申请所提供的技术方案是节点管理器131中所包括的一项功能。

本申请实施例在执行CPU分配控制方案的时候，需要获取CPU的架构及其拓扑结构，且不同的系统架构下的CPU结构是不同的，如目前的商用服务器结构大体可以分为三类，即对称多处理器架构(Symmetric Multi-Processor，SMP)、非一致存储访问架构(Non-Uniform Memory Access，NUMA)，以及海量并行处理架构(Massive Parallel Processing，MPP)。

在一种可能的实施方式中，本申请中各个实施例以服务器结构中使用最广泛的NUMA架构为例进行描述。

示意性的，如图3所示，其示出了本申请实施例所涉及的NUMA架构示意图，且该NUMA架构是以服务器包含两个NUMA节点为例进行示意的，即一台服务器设置有两个Node，且每个Node对应设置有编号，如Node 0、Node 1等等。

如图3所示，Node 0为多个CPU(Core 0、Core 1、Core 2和Core 3)与32G的本地内存(Memory 0)的封装，其中，CPU插槽(Socket 0)用于将多个CPU封装在一起。相应的，Node1的结构可参照Node 0的结构描述。

因此，从图3所示的NUMA架构示意图可以看出，NUMA架构下的服务器的基本特征是具有多个节点模块(即服务器中设置的多个Node)，每个节点模块由多个CPU(如4个)组成，并且每个节点模块具有独立的本地内存(如Memory 32G)、I/O槽口等。

此外，NUMA架构中，各个节点模块之间可以通过互联模块进行连接和信息交互，因此每个CPU可以访问整个服务器的内存，且CPU访问本地内存的速度将远远高于访问远地内存(服务器内其它Node的本地内存)的速度。示意性的，如图3所示，Node 0访问本地内存(Memory 0)的距离是10个单位，而Node 0访问远地内存(Memory 1)的距离是20个单位，相应的，Node 1对于本地内存与远地内存的访问速度亦如此。

本申请各个实施例中，各个CPU的CPU可分配量的初始值设置为1。

请参考图4，其示出了本申请一个示例性实施例示出的CPU分配控制方法的流程图，该示例性实施例用于服务器，该服务器中设置至少两个Node，该方法包括：

步骤401，获取目标任务的CPU需求量。

本申请实施例中的目标任务是指分配至各个服务器中运行的子任务，具体的，由各个服务器中的节点管理器(NodeManager)运行。

在一个示意性的例子中，如图5所示，客户端的应用程序APP1提交待处理作业Job1至分布式资源调度系统中的ResourceManager，且Job1包含了两个子任务Task，各个子任务Task通过分布式资源调度系统的资源协商之后被交由指定的服务器来执行。其中，Job1包括Task 1和Task 2这两个子任务，并且，Task1由第一服务器510中的NodeManager 1运行，Task 2由第二服务器520中的NodeManager 2运行。

在一种可能的实施方式中，服务器在获取到待运行的目标任务之后，需要获取目标任务的CPU需求量，以对目标任务进行CPU分配。

本申请实施例中可通过分布式资源调度系统中的ResourceManager将目标任务的CPU需求传输至运行目标任务的服务器，或者，各个服务器在获取到待运行的目标任务之后，通过目标任务所携带的CPU信息来获取目标任务的CPU需求量，本申请实施例中对各个服务器获取目标任务的CPU需求量的方式不作限定。

步骤402，根据CPU需求量确定目标Node。

由于各个服务器至少设置有两个Node，且不同的Node的CPU可分配量也是不同的，在一种可能的实施方式中，当服务器获取待运行的目标任务之后，根据目标任务的CPU需求量来确定目标任务具体由哪一个Node来运行。其中，Node的CPU可分配量是指该Node内处于空闲未占用的CPU。

在一个示意性的例子中，目标任务的CPU需求量为2个CPU，服务器设置有Node 0和Node 1，且Node 0的CPU可分配量为0.5个CPU，Node 1的CPU可分配量为3个CPU，显然，根据目标任务的CPU需求量，服务器中，仅有Node1的CPU可分配量满足目标任务的CPU需求量，即将Node 1确定为目标Node。

其中，目标Node用于运行目标任务，且目标Node的CPU可分配量大于目标任务的CPU需求量。

步骤403，根据目标Node中CPU的CPU状态，为目标任务分配CPU。

在一种可能的实施方式中，CPU状态包括超线程状态和非超线程状态。当CPU状态为非超线程状态时，本申请各个实施例中的CPU指代的是CPU核心，即在为目标任务进行CPU分配时，CPU的分配以一个CPU核心为最小单位进行分配；当CPU状态为超线程状态时，一个CPU核心虚拟为线程数个CPU核心，即在为目标任务进行CPU分配时，CPU的分配以线程为最小单位进行分配。

在上述示意性的例子中，当CPU状态为非超线程状态时，服务器根据目标任务的CPU需求量(此处为CPU核心的需求量)将Node 1确定为目标Node后，Node1根据所包含的各个CPU核心的CPU可分配量情况为目标任务进行CPU的分配。

在上述示意性的例子中，当CPU状态为超线程状态时，服务器根据目标任务的CPU需求量(此处为线程单位下的CPU核心的需求量)将Node 1确定为目标Node后，Node1根据所包含的各个CPU核心的在线程单位下的CPU可分配量情况为目标任务进行CPU的分配。

步骤404，目标任务在执行状态下，根据服务器的当前CPU使用率，对服务器中的超卖CPU进行超卖控制。

在一种可能的实施方式中，当服务器完成对目标任务的CPU分配后，为了进一步提高服务器的CPU使用率，服务器根据当前CPU使用率，对服务器中的超卖CPU进行超卖控制。

在一种可能的实施方式中，当前CPU使用率为服务器当前所执行的各个任务的CPU需求量总和占服务器实际CPU资源的比例。

在一个示意性的例子中，目标任务的CPU需求量为0.2个CPU，服务器为目标任务分配了1个CPU，由此可见，目标任务所分配到的CPU远远大于目标任务的CPU需求量，即当前的CPU使用率仅为20％，因此造成了CPU资源的浪费，从而降低了服务器的CPU使用率。

在一种可能的实施方式中，目标任务在执行状态下，根据服务器的当前CPU使用率，对服务器中的超卖CPU进行超卖控制。其中，超卖CPU是对服务器中的CPU进行超额分配时虚拟出的CPU，且超卖CPU的CPU可分配量的初始值也设置为1。此外，通过下述示意性的例子对超卖CPU进行阐述。

在一个示意性的例子中，服务器存在有一个空闲的Node，且该Node中的各个CPU仅存在一个CPU(可分配量为1)为空闲状态。此时有任务1(CPU需求量为0.2个CPU)与任务2(CPU需求量为0.5个CPU)，服务器将该Node确定为任务1的目标Node，由于该Node将仅有的CPU分配给了任务1,使得任务2无法被分配CPU。

为了解决上述示意性例子中存在的问题，即服务器无法为更多的任务分配CPU，本申请实施例提供的方案具体为：任务1在执行状态时，服务器当前CPU使用率为20％，服务器将仅有的CPU进行超额分配，得到两个CPU(命名为CPU 1和CPU 2)，CPU 1为任务1当前所分配的CPU，CPU 2为虚拟出的CPU，即为本申请实施例中的超卖CPU，则服务器可将CPU 2分配给任务2，使得任务2在该服务器处运行，此时服务器的CPU使用率达到了70％。其中，由于任务1与任务2的CPU需求量总和为0.7个CPU，因此可见，服务器将仅有的CPU进行超额分配后，不仅实现了CPU使用率的提高，也因任务1与任务2所占用的CPU资源未超过服务器中实际所拥有的CPU资源，保证了各个任务的正常运行。

在上述示意性的例子中，服务器将CPU进行超额分配后，若服务器当前所执行任务的CPU需求量的总和接近或超过服务器中实际所拥有的CPU资源，会导致任务的失败。

为了解决上述问题，在一种可能的实施方式中，服务器对超卖CPU进行超卖控制，如设置一个CPU使用率阈值，限制服务器所执行任务的数量，使得各个任务的CPU需求量总和占服务器实际CPU资源的比例在一个安全范围内。

综上所述，本申请实施例中，服务器获取目标任务的CPU需求量，根据CPU需求量确定出用于执行目标任务的目标Node，以实现服务器满足各个目标任务的CPU资源获取需求；以及，服务器根据目标Node的状态来为各个目标任务分配CPU，且CPU处于超线程状态相较于处于非超线程状态而言，服务器在为目标任务分配CPU的同时保留了更多的CPU资源；此外，服务器在CPU进行超卖的过程中对超卖CPU进行控制，实现了维持了服务器CPU使用率的提高。

请参考图6，其示出了本申请一个示例性实施例示出的CPU分配控制方法的流程图，该示例性实施例用于服务器，该服务器中设置至少两个Node，该方法包括：

步骤601，获取目标任务的CPU需求量。

本步骤的实施方式可以参考上述步骤401，本实施例在此不再赘述。

步骤602，根据CPU需求量确定至少两个Node中的候选Node。

在一种可能的实施方式中，服务器设置有至少两个Node，且服务器遍历计算各个Node的CPU可分配量，将CPU可分配量大于目标任务的CPU需求量的Node标记出来，并将标记的Node确定为候选Node，从而实现了服务器根据CPU需求量确定至少两个Node中的候选Node。

在一个示意性的例子中，目标任务的CPU需求量为2.5个CPU，执行该目标任务的服务器包括有5个Node，分别为Node 0、Node 1、Node 2、Node 3和Node 4，其中，各个Node的CPU可分配量如表一所示，CPU可分配量大于目标任务的CPU需求量的Node为Node 0、Node 1和Node 3，终端将Node 0、Node 1和Node 3进行标记，并将该标记的各个Node确定为候选Node。

表一

步骤603，若存在至少一个候选Node，则将最小CPU可分配量对应的候选Node确定为目标Node。

为了不浪费服务器的CPU资源以执行更多的任务，在一种可能的实施方式中，将最小CPU可分配量对应的候选Node确定为目标Node。

在上述示意性的例子中，服务器将Node 0、Node 1和Node 3确定为候选Node后，如表一所示，服务器对Node 0、Node 1和Node 3按CPU可分配量由小到大进行排序，将CPU可分配量最小的Node确定为目标Node，即示意性例子中的Node 0。

在一种可能的实施方式中，若目标Node中CPU处于超线程状态，则步骤603之后执行步骤604至步骤606；若目标Node中CPU处于非超线程状态，则步骤603之后执行步骤607和步骤608。

步骤604，若目标Node中CPU处于超线程状态，则根据CPU需求量生成CPU需求数组。

一个CPU开启超线程之后可以在服务器中显示为两个CPU，示意性的，在图3的基础上，如图7所示，当CPU开启超线程，各个Node中的CPU核心显示为两个CPU，如在Node 0中，CPU核心包括有Core 0、Core 1、Core 2和Core3，其中，Core 0包括了Thread 0和Thread 1，Core 1、Core 2和Core 3亦如此。

本申请实施例中，CPU开启超线程后的CPU可分配量的初始值设置为2。

在一种可能的实施方式中，若目标Node中CPU处于超线程状态，服务器根据CPU需求量生成CPU需求数组，CPU需求数组中的各个CPU子需求量降序排列，且CPU需求数组中各个CPU子需求量之和等于CPU需求量。

在一种可能的实施方式中，CPU子需求量根据双线程对CPU需求量进行转换后得到，其中，当CPU处于超线程状态时，一个CPU运行任务的线程变为两个CPU运行任务的线程双线程即为双线程。

在一个示意性的例子中，目标Node中CPU处于超线程状态，且目标任务的CPU需求量为4.5个CPU，服务器将CPU需求量按照双线程进行转换，得到转换后的数组为[2,2,0.5]，数组中的各个数据即为CPU子需求量，显然，数组中各个CPU子需求量之和等于CPU需求量。

步骤605，根据目标Node中各个CPU核心的CPU可分配量，生成CPU核心列表。

在步骤403中已指出，当CPU状态为超线程状态时，一个CPU核心虚拟为线程数个CPU核心，即当目标Node中CPU处于超线程状态时，CPU核心的CPU可分配量以线程为单位。

在一种可能的实施方式中，为了在目标Node中选择合适的CPU核心来执行目标任务，服务器将获取目标Node中各个CPU核心的CPU可分配量，并按照CPU可分配量由小到大对目标Node中各个CPU核心进行排序，从而生成CPU核心列表。

在一个示意性的例子中，目标Node的CPU核心包括有Core 0、Core 1、Core 2和Core 3，其中，目标Node中各个CPU核心的CPU可分配量如表二所示，相应的，服务器按照CPU可分配量由小到大对目标Node中各个CPU核心进行排序，从而生成了如表三所示的CPU核心列表。

表二

CPU核心	Core 0	Core 1	Core 2	Core 3
					CPU可分配量	1.0	0.5	2.0	2.0

表三

CPU核心	Core 1	Core 0	Core 2	Core 3
					CPU可分配量	0.5	1.0	2.0	2.0

在一种可能的实施方式中，当存在CPU可分配量相同的CPU核心时，服务器按照CPU核心的编号在CPU核心列表中对CPU可分配量相同的CPU核心进行排序。

如上述示意性例子中的Core 2和Core 3，其中，Core 2和Core 3的CPU可分配量相同，在表三所示的CPU核心列表中，服务器在CPU核心列表中按照Core 2和Core 3的编号进行了排序。

步骤606，根据CPU需求数组和CPU核心列表为目标任务分配CPU。

在一种可能的实施方式中，本步骤包括如下步骤。

一、按序获取CPU需求数组中的CPU子需求量。

在一种可能的实施方式中，CPU需求数组中的各个CPU子需求量降序排列，则服务器按照CPU需求数组中的数据顺序依次从CPU需求数组中获取各个CPU子需求量。

如步骤604示例中的CPU需求数组[2,2,0.5]，服务器第一次获取的CPU子需求量为2，第二次获取的CPU子需求量为2，第三次获取的CPU子需求量为0.5。

二、对于获取到的CPU子需求量，优先分配CPU核心列表中满足CPU子需求量的最小CPU核心。

在一种可能的实施方式中，最小CPU核心的CPU可分配量小于目标Node中其它CPU核心的CPU可分配量。

在一个示意性的例子中，CPU需求数组为[2,2,0.5]，CPU核心列表如表三所示。示意性的，如下表四所示，其示出了各个CPU子需求量能够分配得到的CPU核心。

表四

CPU子需求量为2	Core 2	Core 3	/	/
					CPU可分配量	2.0	2.0	/	/
CPU子需求量为2	Core 2	Core 3	/	/
					CPU可分配量	2.0	2.0	/	/
CPU子需求量为0.5	Core 1	Core 0	Core 2	Core 3
					CPU可分配量	0.5	1.0	2.0	2.0

对于CPU需求数组中第一个数据而言，即CPU子需求量为2时，Core 2和Core 3都能够满足该CPU子需求量的要求，则服务器按照CPU核心的编号顺序将Core 2分配给CPU子需求量2；对于CPU需求数组中第二个数据而言，即CPU子需求量为2时，Core 2和Core 3都能够满足该CPU子需求量的要求，由于Core 2已经分配给了CPU需求数组中CPU子需求量为2的第一个数据，则服务器将Core 3分配给该第二个数据；对于CPU需求数组中第三个数据而言，即CPU子需求量为0.5时，Core 0、Core 1、Core 2和Core 3都能够满足该CPU子需求量的要求，则服务器优先分配CPU核心列表中满足CPU子需求量的最小CPU核心，即将Core 1分配给CPU子需求量0.5。

步骤607，若目标Node中CPU处于非超线程状态，则根据目标Node中各个CPU核心的CPU可分配量，生成CPU核心列表。

未开启超线程的CPU指代CPU核心，即CPU的CPU可分配量以核心为单位。其中，未开启超线程的CPU的拓扑结构如图3所示，本步骤在此不再赘述。

本申请实施例中，CPU未开启超线程时的CPU可分配量的初始值设置为1。

在一种可能的实施方式中，若目标Node中CPU处于非超线程状态，则服务器获取目标Node中各个CPU核心的CPU可分配量，并按照CPU可分配量由小到大对目标Node中各个CPU核心进行排序，从而生成CPU核心列表。

在一个示意性的例子中，目标Node的CPU核心包括有Core 0、Core 1、Core 2和Core 3，其中，目标Node中各个CPU核心的CPU可分配量如表五所示，相应的，服务器按照CPU可分配量由小到大对目标Node中各个CPU核心进行排序，从而生成了如表六所示的CPU核心列表。

表五

CPU核心	Core 0	Core 1	Core 2	Core 3
					CPU可分配量	0.5	0.2	1.0	1.0

表六

CPU核心	Core 1	Core 0	Core 2	Core 3
					CPU可分配量	0.2	0.5	1.0	1.0

步骤608，根据CPU需求量和CPU核心列表为目标任务分配CPU。

在一种可能的实施方式中，服务器遍历CPU核心列表，对CPU核心列表中每一个CPU可分配量大于0的CPU核心按照目标任务的CPU需求量进行分配。

在一个示意性的例子中，目标任务的CPU需求量为0.5，服务器按照表六所示的CPU核心列表的CPU核心按照列表顺序将各个CPU核心分配给目标任务，如首先将Core 1分配给目标任务，其次将Core 0分配给目标任务。

在一种可能的实施方式中，服务器每将一个CPU核心分配给目标任务，服务器将该CPU核心的分配情况以列表的形式与目标任务记录在一起，并更新CPU核心列表与目标任务的CPU需求量，接着服务器继续分配CPU核心给目标任务，直到目标任务的CPU需求量变为0为止。

在一种可能的实施方式中，如图8所示，步骤602之后还包括如下步骤：

步骤801，若不存在候选Node，则确定出至少两个目标Node来执行目标任务。

在一种可能的实施方式中，服务器中的各个Node的CPU可分配量均不满足目标任务的CPU需求量，则服务器进行跨Node以满足目标任务的CPU需求量，通过下述示意性的例子来阐述服务器跨Node进行CPU分配的过程。

在一个示意性的例子中，目标任务的CPU需求量为2.5个CPU，执行该目标任务的服务器包括有5个Node，分别为Node 0、Node 1、Node 2、Node 3和Node 4，其中，各个Node的CPU可分配量如表七所示，显然CPU可分配量大于目标任务的CPU需求量的Node不存在，即服务器不存在候选Node。

表七

服务器中的Node	Node 0	Node 1	Node 2	Node 3	Node 4
						CPU可分配量	0	2.0	1.5	1	1
是否为候选Node	否	否	否	否	否

为了解决表七所示的服务器不存在候选Node的问题，在一种可能的实施方式中，服务器遍历获取各个Node的CPU可分配量，按照Node的编号顺序逐一获取至少两个目标Node，直到至少两个目标Node的CPU可分配量之和大于目标任务的CPU需求量时服务器停止目标Node的获取。

在表七中，如目标任务的CPU需求量为2.5个CPU时，服务器依次将Node1和Node 2确定为目标Node；又如目标任务的CPU需求量为4个CPU时，服务器依次将Node 1、Node 2和Node3确定为目标Node。

在一种可能的实施方式中，服务器确定出至少两个目标Node来执行目标任务后，对于每一个目标Node而言，若目标Node中CPU处于超线程状态，则步骤801之后执行步骤604至步骤606；若目标Node中CPU处于非超线程状态，则步骤801之后执行步骤607和步骤608。

本申请实施例中，服务器根据CPU需求量确定出候选Node之后，将最小满足最小CPU可分配量对应的候选Node确定为目标Node，以实现服务器通过目标Node为目标任务提供CPU资源的同时尽可能节约服务器的整体CPU资源；同时，服务器分别对不同的CPU状态执行相应的分配策略，以实现基于不同CPU状态下的目标Node对目标任务的CPU合理分配；此外，当不存在候选Node时，服务器进行跨Node分配，以解决单个Node的CPU资源不能满足目标任务CPU需求量的问题，进一步提高了服务器中的CPU使用率。

在本申请的各个实施例中，终端的应用程序向分布式资源调度系统提交多个任务，并在获取相应的CPU资源后，由执行任务的服务器运行各个目标任务。

在一种可能的实施方式中，分布式资源调度系统将各个目标任务通过以上实施例所提供的方案分配得到的CPU与应用程序绑定在一起，并存储各个CPU的分配量比例。

在一个示意性的例子中，Node 1中的CPU未开启超线程，且Node 1中的两个CPU核心被分配至应用程序执行相应的任务，其中各个CPU核心的分配情况如下表八所示：

表八

从而，在一种可能的实施方式中，应用程序内各个目标任务与所占用的CPU核心进行绑定，具体包括所占CPU量；此外，各个CPU核心与所执行的目标任务进行绑定，具体包括各个目标任务的分配量比例。

本申请实施例中，通过将各个目标任务通过以上实施例所提供的方案分配得到的CPU与应用程序绑定在一起，实现了多个目标任务共享一个CPU时互补打扰彼此任务正常运行的效果；且通过实时记录CPU核心的分配量比例，使得服务器及时将空闲的CPU进行分配，以提高服务器整体的CPU使用率；此外，通过上述绑定，在应用程序有指定的服务器进行任务执行时，也确保了应用程序与指定服务器之间的正确交互。

在上述实施例中，服务器根据不同的CPU状态为目标任务执行相应的CPU分配策略，虽满足了应用程序中各个待执行任务的CPU资源需求，但对于服务器而言，当存在较多的任务争抢CPU资源时，服务器仍存在无法解决多任务混合执行中出现资源抢占的问题，相应的，服务器也无法提高整体的CPU使用率。

上述实施例中，步骤404已提出解决上述问题的方案，即对服务器中的CPU进行超卖，并根据服务器的当前CPU使用率对超卖CPU进行超卖控制。

具体的，在一种可能的实施方式中，在图4的基础上，如图9所示，步骤404包括步骤901至步骤903。

其中，步骤404中已对超卖CPU、超卖控制、以及服务器的CPU使用率进行了阐述，本实施例中的各个步骤对此不再赘述。

步骤901，每隔预定时间间隔获取当前CPU使用率。

在一种可能的实施方式中，服务器每隔预定时间间隔获取当前CPU使用率，通过获取实时的CPU使用率，服务器能够监控CPU资源的使用情况，以防止在出现CPU使用率过高或CPU资源抢占完毕时对服务器正常运行造成影响。

步骤902，若当前CPU使用率高于使用率阈值，则根据下调策略下调超卖CPU的算力提供比例。

在一种可能的实施方式中，服务器中所执行的目标任务包括在线任务和离线任务，针对在线任务与离线任务混合部署的情况，服务器对各个CPU设置有使用率阈值，以保障在线任务的正常执行，当服务器的当前CPU使用率超过该使用率阈值，在线任务会产生失败。

在一种可能的实施方式中，若当前CPU使用率高于使用率阈值，服务器根据下调策略下调超卖CPU的算力提供比例(Ratio)，其中算力是指CPU的计算算力，且超卖CPU的初始的计算能力与未进行超卖的CPU的计算能力一致。

首先，对超卖CPU的Ratio以及与超卖CPU的Ratio相关的名词进行解释。

超卖CPU的算力上限(OversoldQuota)：超卖CPU能够提供的计算能力上限，不同的时段可提供的计算能力是不同的。如在线任务高峰期，各个应用程序包含较多的任务，即对CPU的需求量较大，那么相应的超卖CPU能够提供的计算能力就要降低，以保障服务器中非超卖CPU的正常资源提供；又如在线任务低谷期，各个应用程序包含较少的任务，即对CPU的需求量较小，那么相应的超卖的CPU能提供的计算能力要提高，以节约服务器中非超卖CPU的资源。

超卖CPU的Ratio：其中超卖CPU的Ratio用于控制超卖CPU能够提供的计算能力的比例，根据服务器实际的CPU使用率情况自适应调整，变化范围为[0.1-1.0]。

超卖CPU的实际所提供算力(RealOversoldQuota)：RealOversoldQuota指超卖CPU实际提供的计算能力，其中RealOversoldQuota＝OversoldQuota*Ratio。

通过上述内容可知，超卖CPU的算力提供比例用于指示超卖CPU的实际所提供算力占超卖CPU的算力上限的比例。

在本申请实施例中，为了数据表达的便捷性，OversoldQuota和RealOversoldQuota所表示的数据是对应计算能力下运算指令次数的倍数。如OversoldQuota为0.5，是指超卖CPU在固定时间内可执行运算指令次数的0.5倍。

在一种可能的实施方式中，下调策略具体为服务器根据预设下调比例，指数下调超卖CPU的算力提供比例。下面通过一个示意性的例子对下调策略进行具体阐述。

在一个示意性的例子中，如图10所示，其示出了本示意性例子中关于下调策略的相关数据。其中，服务器的使用率阈值(CPUThreshold)设置为80％；OversoldQuota包括如下取值：[0.2,0.5,0.8]，分别对应了在线任务处于高峰期、平稳期和低谷期时超卖CPU的算力上限；超卖CPU的Ratio的初始值为1；超卖CPU的OversoldQuota的初始值为0.5，即表示该示意性例子中的在线任务处于平稳期；预设下调比例设置为0.5，即每一次下调时的Ratio为上一次下调时Ratio的0.5倍；相应的，根据RealOversoldQuota、Ratio和OversoldQuota之间的数值关系(RealOversoldQuota＝OversoldQuota*Ratio)，在Ratio和OversoldQuota都确定的情况下，RealOversoldQuota在本示意性例子中初始值为0.5。

此外，在对超卖CPU进行超卖监控的时候，通过图10所示的监控机制(Monitoring)来实现，具体为：服务器定时检查时间，如服务器每隔15s检查一次服务器的当前CPU使用率，其中，图10所示的check表示当前检查次数。

当服务器的当前CPU使用率高于使用率阈值时，进行下调策略，对超卖CPU的RealOversoldQuota执行压制过程(suppressing)。监控机制(Monitoring)设置检查时间为15s，则在Check 1(第一次检查)时，Ratio的初始值1.0依据0.5倍的预设下调比例变成0.5，此时超卖CPU的RealOversoldQuota随之减半，由初始值0.5变成0.25，其中，Check 2、Check3与Check 1的数据变化规律一致，直至进行到Check 4，超卖CPU的Ratio达到了最低值，此时监控时间进行了1分钟，超卖CPU的RealOversoldQuota也由初始值0.5降至低于0.05的数值，则超卖CPU能够提供的计算能力将小于5％，实验证明超卖CPU在5％计算能力下对在线服务不会造成实际的影响。服务器通过监控机制继续对超卖CPU监控下去。

在一种可能的实施方式中，如果发现当前CPU使用率始终大于CPUThreshold，服务停止运行离线任务(Kill BatchJob)，或者，服务器维持超卖CPU5％的算力，即对超卖CPU进行持续压制。

如图11所示，其示出了监控时间为1分钟时超卖CPU的RealOversoldQuota数值变化图，根据图11也侧面体现出在下调策略中，服务器根据预设下调比例指数下调超卖CPU的Ratio时，压制过程(suppressing)是一个RealOversoldQuota指数降低的过程。

步骤903，若当前CPU使用率低于使用率阈值，则根据上调策略上调超卖CPU的算力提供比例。

在一种可能的实施方式中，服务器在开始进行超卖监控时检测到当前CPU使用率低于CPUThreshold，或者，服务器通过下调策略使得当前CPU使用率低于CPUThreshold时，则服务器进行上调策略，即对超卖CPU的RealOversoldQuota开始执行恢复过程(recovering)。

在一种可能的实施方式中，上调策略具体为根据预设上调数值，线性上调超卖CPU的算力提供比例。下面继续通过图10所示的示意性例子进行具体阐述。

如图10所示，恢复过程(recovering)中，预设上调数值设置为0.02，监控机制设置检查时间为15s。在Check 1时，Ratio的当前数值0.1根据预设上调数值0.02变成0.12，此时超卖CPU的RealOversoldQuota随之增加预设CPU上调数值，由下调策略中对超卖CPU进行持续压制下的数值0.05变成0.06。

在一种可能的实施方式中，预设CPU上调数值可以自定义进行设置，但通常情况下，为了保障恢复过程的稳定性，预设CPU上调数值自定义为较小的数据，从而体现出压制过程(suppressing)与恢复过程(recovering)中超卖CPU的RealOversoldQuota“速降慢增”的数值变化特点。

其中，Check 2、Check 3…与Check 1的数据变化规律一致，直至进行到Check45，超卖CPU的Ratio达到了最大值1.0，此时监控时间进行了675秒，超卖CPU的RealOversoldQuota也由数值0.05增至初始值0.5。

如图12所示，其示出了监控时间为675秒时超卖CPU的RealOversoldQuota数值变化图，根据图12也侧面体现出在上调策略中，服务器根据预设上调数值线性上调超卖CPU的Ratio时，恢复过程(recovering)是一个RealoversoldQuota线性增长的过程。

在一种可能的实施方式中，在图6的基础上，步骤606和步骤608之后各自执行步骤901至步骤903。即，在CPU处于超线程状态时，服务器将超线程时以线程为单位的CPU进行超卖，并根据服务器的当前CPU使用率对该超卖CPU进行超卖控制；在CPU处于非超线程状态时，服务器将非超线程时以核心为单位的CPU进行超卖，并根据服务器的当前CPU使用率对该超卖CPU进行超卖控制。

本申请实施例中，服务器通过下调策略和上调策略对超卖CPU进行动态控制，使得服务器通过超卖CPU满足多任务混合部署情况时，还通过超卖监控保障在线服务的正常运行，有效地提高了服务器的CPU使用率，从而在不增加额外服务器的情况下服务器能够运行更多的任务，进而提升了服务器的运营效率以及降低了服务器的运营成本。

请参考图13，其示出了本申请一个实施例提供的CPU分配控制装置的结构框图。该装置可以通过软件、硬件或者两者的结合实现成为计算机设备的全部或一部分。该装置包括：

需求量获取模块1301，用于获取目标任务的CPU需求量；

节点确定模块1302，用于根据所述CPU需求量确定目标Node，所述目标Node用于执行所述目标任务，且所述目标Node的CPU可分配量大于所述CPU需求量；

CPU分配模块1303，用于根据所述目标Node中CPU的CPU状态，为所述目标任务分配CPU，所述CPU状态包括超线程状态和非超线程状态；

CPU控制模块1304，用于所述目标任务在执行状态下，根据所述服务器的当前CPU使用率，对所述服务器中的超卖CPU进行超卖控制，所述超卖CPU是对所述服务器中的CPU进行超额分配时虚拟出的CPU。

可选的，所述CPU分配模块1303，包括：

数组生成子模块，用于若所述目标Node中CPU处于所述超线程状态，则根据所述CPU需求量生成CPU需求数组，所述CPU需求数组中各个CPU子需求量之和等于所述CPU需求量，且所述CPU子需求量根据双线程对所述CPU需求量进行转换后得到；

第一列表生成子模块，用于根据所述目标Node中各个CPU核心的CPU可分配量，生成CPU核心列表，所述CPU核心的CPU可分配量以线程为单位；

第一CPU分配子模块，用于根据所述CPU需求数组和所述CPU核心列表为所述目标任务分配CPU。

所述CPU需求数组中的各个CPU子需求量降序排列；

可选的，所述第一CPU分配子模块，用于按序获取所述CPU需求数组中的CPU子需求量；

对于获取到的所述CPU子需求量，优先分配所述CPU核心列表中满足所述CPU子需求量的最小CPU核心，所述最小CPU核心的CPU可分配量小于所述目标Node中其它CPU核心的CPU可分配量。

可选的，所述CPU分配模块1303，包括：

第二列表生成子模块，用于若所述目标Node中CPU处于所述非超线程状态，则根据所述目标Node中各个CPU核心的CPU可分配量，生成CPU核心列表，所述CPU核心的CPU可分配量以核心为单位；

第二CPU分配子模块，用于根据所述CPU需求量和所述CPU核心列表为所述目标任务分配CPU。

可选的，所述节点确定模块1302，包括：

候选节点确定子模块，用于根据所述CPU需求量确定所述至少两个Node中的候选Node，所述候选Node的CPU可分配量大于所述CPU需求量；

目标节点确定子模块，用于若存在至少一个所述候选Node，则将最小CPU可分配量对应的所述候选Node确定为所述目标Node。

可选的，所述CPU控制模块1304，包括：

使用率获取子模块，用于每隔预定时间间隔获取所述当前CPU使用率；

下调策略子模块，用于若所述当前CPU使用率高于使用率阈值，则根据下调策略下调所述超卖CPU的算力提供比例，所述算力提供比例用于指示所述超卖CPU所提供算力占算力上限的比例；

上调策略子模块，用于若所述当前CPU使用率低于所述使用率阈值，则根据上调策略上调所述超卖CPU的所述算力提供比例。

可选的，所述下调策略子模块，用于根据预设下调比例，指数下调所述超卖CPU的所述算力提供比例；

可选的，所述上调策略子模块，用于根据预设上调数值，线性上调所述超卖CPU的所述算力提供比例。

可选的，所述服务器为区块链节点服务器。

请参考图14，其示出了本申请一个实施例提供的服务器的结构示意图。该服务器用于实施上述实施例提供的CPU分配控制方法。具体来讲：

所述服务器1400包括中央处理单元(CPU)1401、包括随机存取存储器(RAM)1402和只读存储器(ROM)1403的系统存储器1404，以及连接系统存储器1404和中央处理单元1401的系统总线1405。所述服务器1400还包括帮助计算机内的各个器件之间传输信息的基本输入/输出系统(I/O系统)1406，和用于存储操作系统1413、应用程序1414和其他程序模块1415的大容量存储设备1407。

所述基本输入/输出系统1406包括有用于显示信息的显示器1408和用于用户输入信息的诸如鼠标、键盘之类的输入设备1409。其中所述显示器1408和输入设备1409都通过连接到系统总线1405的输入输出控制器1410连接到中央处理单元1401。所述基本输入/输出系统1406还可以包括输入输出控制器1410以用于接收和处理来自键盘、鼠标、或电子触控笔等多个其他设备的输入。类似地，输入输出控制器1410还提供输出到显示屏、打印机或其他类型的输出设备。

所述大容量存储设备1407通过连接到系统总线1405的大容量存储控制器(未示出)连接到中央处理单元1401。所述大容量存储设备1407及其相关联的计算机可读介质为服务器1400提供非易失性存储。也就是说，所述大容量存储设备1407可以包括诸如硬盘或者CD-ROM驱动器之类的计算机可读介质(未示出)。

不失一般性，所述计算机可读介质可以包括计算机存储介质和通信介质。计算机存储介质包括以用于存储诸如计算机可读指令、数据结构、程序模块或其他数据等信息的任何方法或技术实现的易失性和非易失性、可移动和不可移动介质。计算机存储介质包括RAM、ROM、EPROM、EEPROM、闪存或其他固态存储其技术，CD-ROM、DVD或其他光学存储、磁带盒、磁带、磁盘存储或其他磁性存储设备。当然，本领域技术人员可知所述计算机存储介质不局限于上述几种。上述的系统存储器1404和大容量存储设备1407可以统称为存储器。

根据本申请的各种实施例，所述服务器1400还可以通过诸如因特网等网络连接到网络上的远程计算机运行。也即服务器1400可以通过连接在所述系统总线1405上的网络接口单元1411连接到网络1412，或者说，也可以使用网络接口单元1411来连接到其他类型的网络或远程计算机系统。

所述存储器中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、至少一段程序、代码集或指令集经配置以由一个或者一个以上处理器执行，以实现上述CPU分配控制方法中各个步骤的功能。

本申请实施例还提供一种计算机可读存储介质，该存储介质中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、所述至少一段程序、所述代码集或指令集由所述处理器加载并执行以实现如上述各个实施例提供的CPU分配控制方法。

可选地，该计算机可读存储介质可以包括：只读存储器(ROM，Read Only Memory)、随机存取记忆体(RAM，Random Access Memory)、固态硬盘(SSD，Solid State Drives)或光盘等。其中，随机存取记忆体可以包括电阻式随机存取记忆体(ReRAM,Resistance RandomAccess Memory)和动态随机存取存储器(DRAM，Dynamic Random Access Memory)。

上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。以上所述仅为本申请的可选实施例，并不用以限制本申请，凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims

1.一种CPU分配控制方法，其特征在于，所述方法用于服务器，所述服务器中设置至少两个节点Node，所述方法包括：

获取目标任务的CPU需求量；

2.根据权利要求1所述的方法，其特征在于，所述根据所述目标Node中CPU的CPU状态，为所述目标任务分配CPU，包括：

若所述目标Node中CPU处于所述超线程状态，则根据所述CPU需求量生成CPU需求数组，所述CPU需求数组中各个CPU子需求量之和等于所述CPU需求量，且所述CPU子需求量根据双线程对所述CPU需求量进行转换后得到；

根据所述目标Node中各个CPU核心的CPU可分配量，生成CPU核心列表，所述CPU核心的CPU可分配量以线程为单位；

根据所述CPU需求数组和所述CPU核心列表为所述目标任务分配CPU。

3.根据权利要求2所述的方法，其特征在于，所述CPU需求数组中的各个CPU子需求量降序排列；

所述根据所述CPU需求数组和所述CPU核心列表为所述目标任务分配CPU，包括：

按序获取所述CPU需求数组中的CPU子需求量；

4.根据权利要求1所述的方法，其特征在于，所述根据所述目标Node中CPU的CPU状态，为所述目标任务分配CPU，包括：

若所述目标Node中CPU处于所述非超线程状态，则根据所述目标Node中各个CPU核心的CPU可分配量，生成CPU核心列表，所述CPU核心的CPU可分配量以核心为单位；

根据所述CPU需求量和所述CPU核心列表为所述目标任务分配CPU。

5.根据权利要求1至4所述的方法，其特征在于，所述根据所述CPU需求量确定目标Node，包括：

根据所述CPU需求量确定所述至少两个Node中的候选Node，所述候选Node的CPU可分配量大于所述CPU需求量；

若存在至少一个所述候选Node，则将最小CPU可分配量对应的所述候选Node确定为所述目标Node。

6.根据权利要求1至4任一所述的方法，其特征在于，所述根据所述服务器的当前CPU使用率，对所述服务器中的超卖CPU进行超卖控制，包括：

每隔预定时间间隔获取所述当前CPU使用率；

若所述当前CPU使用率高于使用率阈值，则根据下调策略下调所述超卖CPU的算力提供比例，所述算力提供比例用于指示所述超卖CPU所提供算力占算力上限的比例；

若所述当前CPU使用率低于所述使用率阈值，则根据上调策略上调所述超卖CPU的所述算力提供比例。

7.根据权利要求1至4任一所述的方法，其特征在于，所述服务器为区块链节点服务器。

8.一种CPU分配控制装置，其特征在于，所述装置用于服务器，所述服务器中设置至少两个节点Node，所述装置包括：

需求量获取模块，用于获取目标任务的CPU需求量；

9.一种服务器，其特征在于，所述服务器包括处理器和存储器；所述存储器存储有至少一条指令，所述至少一条指令用于被所述处理器执行以实现如权利要求1至7任一所述的CPU分配控制方法。

10.一种计算机可读存储介质，其特征在于，所述存储介质存储有至少一条指令，所述至少一条指令用于被处理器执行以实现如权利要求1至7任一所述的CPU分配控制方法。