CN110764912A - 一种自适应任务调度器及方法 - Google Patents
一种自适应任务调度器及方法 Download PDFInfo
- Publication number
- CN110764912A CN110764912A CN201911021198.0A CN201911021198A CN110764912A CN 110764912 A CN110764912 A CN 110764912A CN 201911021198 A CN201911021198 A CN 201911021198A CN 110764912 A CN110764912 A CN 110764912A
- Authority
- CN
- China
- Prior art keywords
- node
- task
- utilization rate
- performance
- cluster
- 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.)
- Granted
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/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
- 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
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
- G06N3/00—Computing arrangements based on biological models
- G06N3/004—Artificial life, i.e. computing arrangements simulating life
- G06N3/006—Artificial life, i.e. computing arrangements simulating life based on simulated virtual individual or collective life forms, e.g. social simulations or particle swarm optimisation [PSO]
-
- 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)
- Artificial Intelligence (AREA)
- Life Sciences & Earth Sciences (AREA)
- Health & Medical Sciences (AREA)
- Biomedical Technology (AREA)
- Biophysics (AREA)
- Computational Linguistics (AREA)
- Data Mining & Analysis (AREA)
- Evolutionary Computation (AREA)
- General Health & Medical Sciences (AREA)
- Molecular Biology (AREA)
- Computing Systems (AREA)
- Mathematical Physics (AREA)
- Debugging And Monitoring (AREA)
Abstract
本发明公开一种自适应任务调度器及方法,属于分布式流处理系统负载均衡调度技术领域,该调度器主要包括性能监控数据采集模块、平滑加权轮询任务调度模块以及基于蚁群算法的任务调度模块,采用本发明的自适应任务调度器进行任务调度的方法在任务运行初始阶段,采用平滑加权轮询任务调度算法,根据节点的权重分配任务,在保证选中次数不变的情况下,使得节点不被连续选中;当集群的负载超过设定阈值的时候,为避免拖延任务集合的整体完成时间,使用基于蚁群算法的负载均衡算法在一定的迭代次数内计算出最优的任务分配方案,待集群资源降低到设定阈值下时候,继续采用平滑加权轮询算法。
Description
技术领域
本发明涉及分布式流处理系统负载均衡调度技术领域,尤其涉及一种自适应任务调度器及方法。
背景技术
在流计算集群中,任务调度模块是非常重要的一部分。任务调度模块负责把Task分配给指定的Slot去调度执行,保证整个集群中每个节点的负载均衡。经典的负载均衡算法有轮询法(Round Robin)、随机法(Random)、源地址哈希法(Hash)、加权轮询法(WeightRound Robin)、加权随机法(Weight Random)、最小连接数法(Least Connections)。上述的负载均衡算法通常都被用于各种负载均衡的模型中,而很多负载均衡的算法都是基于上面负载均衡算法改进的。而常见的大数据流计算框架里面,常见的调度器通常都是轮询实现的。这样的优势在于当集群里面所有的节点都是同等的性能时Task被整体均衡分配,从而就能使得集群负载均衡。但是在异构集群里面,每个节点的性能存在较大差别,若还采用轮询的算法,就会造成性能好的节点和性能较差节点被分配同等的任务。这样整体任务集合的完成时间、延迟时间、吞吐量都会受到影响。
发明内容
针对上述现有技术的不足,本发明提供一种自适应任务调度器及方法。
为解决上述技术问题,本发明所采取的技术方案是:一种自适应任务调度器,包括:性能监控数据采集模块、平滑加权轮询任务调度模块以及基于蚁群算法的任务调度模块;
所述性能监控数据采集模块包括:节点CPU利用率监控数据采集单元、节点内存利用率监控数据采集单元、监控数据上传单元、监控数据存储单元和API接口开放单元;
所述节点CPU利用率监控数据采集单元通过计算空闲时间周期和总的时钟周期来计算CPU利用率;
所述节点内存利用率监控数据采集单元通过计算空闲的内存空间和总的内存空间来计算内存利用率;
所述监控数据上传单元通过使用Netty网络通信框架,将每个集群中Slave节点的CPU利用率和内存利用率上传给集群中Master节点;
所述监控数据存储单元使用Redis内存KV数据库存储性能数据,并配置LRU的模式,保存最近的数据,能够加快监控数据的访问;
所述API接口开放单元通过使用Web技术,开放出Http的接口,供集群通过HttpClient调用;
所述平滑加权轮询任务调度模块用于在初始调度时采用平滑轮询任务调度算法达到集群负载均衡;
所述基于蚁群算法的任务调度模块用于当集群中整体资源使用达到规定阈值时,计算出全局最优任务分配方案供后续的任务分配使用,当集群资源降到阈值以下,则继续采用所述平滑加权轮询任务调度算法对任务进行分配。
采用上述自适应任务调度器进行任务调度的方法,其流程如图1所示,包括如下步骤:
步骤1:获取CPU利用率、内存利用率、总内存大小以及上传性能数据;
步骤1.1:Linux的实时性能监控数据存放在/proc文件夹下的性能记录文件里;
步骤1.2:用正则表达式去解析步骤1.1所述文件夹下对应空闲的时钟周期idleCPU、总的时钟周期totalCPU,利用idleCPU与totalCPU的比值即可得到CPU利用率;
步骤1.3:用正则表达式去解析步骤1.1所述文件夹下的空闲内存idleMem、总内存totalMem,利用idleMem与totalMem的比值即可得到内存利用率;
步骤1.4:利用Netty高性能NIO框架在每个Slave节点和Master节点建立Socket连接;
步骤1.5:Master节点向Slave节点发送Hello消息,表示Master节点希望能获取到Salve节点的性能数据;
步骤1.6:Slave节点收到Hello消息后,上传自己的性能数据给Master节点,于此同时,Slave节点与Master节点保持心跳联系,避免建立的连接关闭。
步骤2:在Master节点持久化Slave节点传递过来的性能数据以及Master自身的性能数据,并且配置缓存淘汰策略,清理过时的数据;
步骤2.1:Master节点开启一个定时任务,获取到自身的CPU利用率、内存利用率,并保持与Slave节点的发送时间周期一致;
步骤2.2:Master节点反序列化从Slave节点传输过来的数据,并为每个Slave节点构建一个List存放到Redis里面;
步骤2.3:为了避免数据的冗余造成Redis压力大,为Reids配置LRU的缓存淘汰策略,清理过时的数据,所述步骤1和步骤2中节点的工况示意如图2所示。
步骤3:提供性能数据HTTP调用接口,把获取集群性能的函数封装成一个HTTP接口,并且这个HTTP接口供外部调用并提供容错的处理;
步骤3.1:利用Spring MVC框架,把获取集群性能的函数封装成一个HTTP接口,这个接口返回一个Json字符串,供集群或者其他系统调用并解析出数据从而利用;
步骤3.2:采用在本地内存里面缓存最近的性能数据的方法,当出现网络延迟或者错误的时候,直接返回缓存的数据。
步骤4:利用步骤3调用的性能数据作为参考依据,采用自适应任务调度器进行任务调度。
步骤4.1:通过HTTP调用性能函数获取到性能数据,根据从Slave节点发送过来的性能监控数据,按照CPU利用率:内存利用率=9:1的比例,计算每个节点的权重,公式如下:
Weight=PCPU*0.9+PMemory*0.1
其中,PCPU为CPU利用率,PMemory为内存利用率,Weight为节点权重;
步骤4.2:初始化任务分配,调度器根据步骤4.1得到的权重大小,根据权重大小分配这个选中节点的Slot给Task;
步骤4.3:采用平滑加权轮询任务调度算法,使得权重大的节点被选中的次数不变,但是它被选中的时机分布均匀,而不是连续多次选中,其流程如图3所示;
步骤4.3.1:初始化当前权重,令当前权重等于权利要求6步骤4.1所述每个节点的权重;初始化有效权重effectiveWeight等于权利要求6步骤4.1所述每个节点的权重,初始化变量tw=0;
步骤4.3.2:将当前节点的当前权重currentWeight,用变量instance记录;
步骤4.3.3:判断是否遍历完所有节点,如果是则执行步骤4.3.6;如果不是则判断下一个节点的当前权重currentWeight是否大于instance,并执行步骤4.3.4;
步骤4.3.4:如果是则用该节点的当前权重currentWeight更新instance,再执行步骤4.3.5;否则直接执行步骤4.3.5;;
步骤4.3.5:将步骤4.3.4所述节点的有效权重effectiveWeight加上变量tw的值,并将该节点的当前权重currentWeight加上有效权重effectiveWeight重新构成该节点的当前权重currentWeight,转至执行步骤4.3.3;
步骤4.3.6:把最大的当前权重currentWeight的值的减去所有节点的权重之和,降低instance的currentWeight,并返回这个instance节点作为选中节点。
步骤4.4:在中间运行过程中,如果达到集群设定资源阈值,则启用基于蚁群算法的负载均衡算法,根据集群的实时资源数据,在一定的迭代次数内,为任务集合中的每个任务选择一个最佳的分配方案,使得整个集群的运行状态处于最佳状态,相应的计算时间也相应的减少,其流程如图4所示。
步骤4.4.1:把将要参与调度的任务集合赋值给tasks[i];将每个节点的CPU利用率、内存利用率等性能数据按照9:1的比例复制给nodes[i];初始化蚂蚁的数量antcount,迭代次数iteratorNum,初始化信息素浓度矩阵,将信息素浓度矩阵pheromoneMatrix[i][j]中所有元素置为1,pheromoneMatrix矩阵的每一行中最大信息素浓度的下标记为maxPheromoneMatrix,采用随机分配策略的蚂蚁的临界编号记为criticalPointMatrix;
其中,tasks[i]表示任务i的规模,这里用任务处理的数据集大小来初始化tasks;nodes[i]表示节点i的处理性能;pheromoneMatrix[i][j]表示将任务i分配给节点j这条路径的信息素浓度;
步骤4.4.2:遍历每个任务、每个节点,计算任务执行时间数组timeMatrix[i][j];
其中,timeMatrix[i][j]表示任务i分配给节点j所需的时间;
步骤4.4.3:迭代搜索过程:
步骤4.4.3.1:初始化一个三维数组pathMatrix_allAnt,用以保存每次迭代过程中所有蚂蚁的路径;初始化一个二维数组pathMatrix_oneAnt,用以保存单只蚂蚁分配的路径,并将pathMatrix_oneAnt加入到pathMatrix_allAnt中保存;
步骤4.4.3.2:任务分配assignOneTask,任务分配函数负责将一个指定的任务按照分配策略分配给某一节点处理:
其中,分配策略有以下两种:
(1)按信息素浓度分配,将任务分配给本行中信息素浓度最高的节点pheromoneMatrix[taskCount]处理;
(2)随机分配,将任务随意分配给随机一个节点处理;
以上两种策略是根据人为设置的蚂蚁的临界编号criticalPointMatrix区间进行分类选择的;
将任务分配后的路径结果保存到数组pathMatrix_allAnt和数组pathMatrix_oneAnt中;
步骤4.4.3.3:计算每只蚂蚁的实际任务处理时间;
每迭代完一次,都要计算每只蚂蚁分配的所有任务的完成时间,即所有节点任务完成时间的最大值;
步骤4.4.3.4:更新信息素浓度矩阵pheromoneMatrix[i][j]:
模拟信息素的挥发,将所有信息素浓度降低p%;
找出本次迭代中最短路径,并将该条路径的信息素浓度提高q%;
步骤4.4.3.5:找出pheromoneMatrix[i][j]中每一行中最大信息素浓度,更新maxPheromoneMatrix数组;
步骤4.4.3.5:更新criticalPointMatrix数组:
①计算最大信息素的概率,计算方式如下:
②计算蚂蚁的临界下标,用上一步计算的maxphe乘以蚂蚁的数量,计算方式如下:
indexbound=maxphe*antcount
确定tasks[i]的临界下标indexbound,在indexbound之前的蚂蚁选择最大信息素的节点,在indexbound之后的蚂蚁选择一个随机节点,其中indexbound是criticalPointMatrix中的一个元素;
步骤4.4.3.6:重复执行步骤4.4.3.2至步骤4.4.3.5,直到迭代次数超过迭代次数iteratorNum,跳出循环;
步骤4.4.4:根据步骤4.4.3.3计算的每次迭代后,每只蚂蚁的实际任务处理时间就可以计算每次迭代用时最短的蚂蚁,再取出所有迭代中用时最短的蚂蚁,这只蚂蚁所对应任务分配方案就是全局的最优任务分配方案,即按这个方案分配任务给对应的节点,总体所用的时间最短。
采用上述技术方案所产生的有益效果在于:
1、本发明实现了一个实时性能监控中间件,实时获取到集群中各个节点的CPU使用率和内存使用率等数据;
2、本发明在任务运行初始的时候,采用一种平滑加权轮询任务调度算法。根据节点的权重分配任务给节点的Slot,在维持选中次数不变的情况下,使选中的时机相对分散;
3、本发明在运行过程中,当集群资源达到设定阈值时,又采用基于蚁群算法的负载均衡算法,使得集群重新负载均衡。该算法模拟蚁群寻找最短路径觅食的行为,在一定迭代次数内,寻找一种全局任务分配方案把Task分配给节点,从而使得集群的性能最优,任务集合的完成时间,延时,吞吐量也相对于调度默认算法有减少。待集群资源降低到设定阈值下时候,继续采用初始的平滑加权轮询算法。
4、本发明设计的调度器能够使得异构集群中任务调度负载均衡,相应的总运行时间,延时,吞吐量比默认调度算法有提升。
附图说明
图1为本发明采用自适应任务调度器进行任务调度的方法流程图;
图2为本发明自适应任务调度器节点工况示意图;
图3为本发明平滑加权轮询任务调度算法流程图;
图4为本发明基于蚁群算法的负载均衡算法的流程图;
图5为本发明实施例中CPU性能指标展示图;
图6为本发明实施例中内存性能指标展示图;
图7为本发明实施例中集群性能可视化图;
图8为本发明实施例中平滑加权轮询任务调度演示图。
具体实施方式
下面结合附图和实施例,对本发明的具体实施方式作进一步详细描述。以下实施例用于说明本发明,但不用来限制本发明的范围。
本实施例将一种自适应滤波器及方法运用到大数据分析系统Gaia中,在默认情况下,Gaia调度器将集群中所有的节点视为同构的,这样采用轮询调度的调度方式更简单、快捷。但是在试验条件下,异构的集群即集群中各个节点性能有很大差异,那么Gaia采用的这种默认调度模式可能使得集群中某个节点超过正常的负载。这样会拖延整体任务集合的完成时间。本实施例通过一种自适应任务调度器,在异构集群的模式下,初始使用平滑轮询任务调度算法。超过集群预警负载后,使用基于蚁群算法的负载均衡算法得到完整的任务分配方案。按照此方案调度,集群的性能将会更好。
解决Gaia在异构集群可能存在的性能问题,核心点在于考虑集群中每个节点实时的性能参数,根据实时资源状况分配任务给Slot。由于调度是在Master节点完成的,因此,Slave需要将自身的CPU使用率,内存使用率等数据发送给Master。在Slave和Master通信的过程中,尽量异步处理请求不阻塞。这里采用了高性能NIO框架Netty异步处理请求,这样就能很快的响应请求。在上传性能数据的过程中,设置服务端的连接属性Keep-alive,来保持客户端和服务端的长连接活性。服务端定时给客户端发送心跳信息,如果客户端有节点宕机了,服务端能立刻感应到并将宕机节点剔除。由于需要获取最近一段时间节点性能信息,因此在Master节点将性能信息持久化。为了能更快的存取,选择Redis KV数据库,能快速的存取。并且采用LRU的缓存策略淘汰过期的数据,上述过程中节点工况示意如图2所示。
自适应任务调度器的整体流程如图1所示,为了使得集群的计算资源被充分利用,按照权重轮询分配即可实现这个目标。但是按照权重轮询分配容易造成初始权重大的节点一直被选中,最终可能会过负载。因此,用平滑轮询任务调度算法可以避免这个问题。它在保证选中次数不变的情况下,使得节点不是被连续选中的,而是相对分散的。当集群的负载超过设定阈值的时候,为避免拖延任务集合的整体完成时间,考虑使用基于蚁群算法的负载均衡算法在一定的迭代次数内计算出最优的任务分配方案。按照最优方案分配任务能使得集群处于最佳状态。
步骤1:获取CPU利用率、内存利用率、总内存大小以及上传性能数据;
步骤1.1:Linux的实时性能监控数据存放在/proc文件夹下的性能记录文件里;
步骤1.2:用正则表达式去解析步骤1.1所述文件夹下对应空闲的时钟周期idleCPU、总的时钟周期totalCPU,利用idleCPU与totalCPU的比值即可得到CPU利用率;
其中,idle为空闲的时钟周期,user+system+idle+nice+wait+irq+softirq为总时钟周期,本实施例展示的CPU性能指标如图5所示;
步骤1.3:用正则表达式去解析步骤1.1所述文件夹下的空闲内存idleMem、总内存totalMem,利用idleMem与totalMem的比值即可得到内存利用率;
计算内存的使用率公式如下:
本实施例中如图6所示,展示了内存的性能指标,其中idleMem的取值为图6中的memfree,totalMem的取值为图6中的memtotal。
步骤1.4:利用Netty高性能NIO框架在每个Slave节点和Master节点建立Socket连接;
步骤1.5:Master节点向Slave节点发送Hello消息,表示Master节点希望能获取到Salve节点的性能数据;
步骤1.6:Slave节点收到Hello消息后,上传自己的性能数据给Master节点,于此同时,Slave节点与Master节点保持心跳联系,避免建立的连接关闭。
步骤2:在Master节点持久化Slave节点传递过来的性能数据以及Master自身的性能数据,并且配置缓存淘汰策略,清理过时的数据;
步骤2.1:Master节点开启一个定时任务,获取到自身的CPU利用率、内存利用率,并保持与Slave节点的发送时间周期一致;
步骤2.2:Master节点反序列化从Slave节点传输过来的数据,并为每个Slave节点构建一个List存放到Redis里面;
步骤2.3:在Redis里面存储的格式通常是以Json的格式,例如{"127.0.0.1":["0.4:4.0:0.4","4.0:0.4:4.0","0.4:4.0:0.4"]}。key为IP地址,value代表3次监控数据,分别是CPU使用率,内存使用率,总内存大小。由于在调度的时候,只利用最近一段时间的性能数据。为了避免数据的冗余造成Redis压力大,为Reids配置LRU的缓存淘汰策略,清理过时的数据,这样能节省内存,所述步骤1和步骤2中节点的工况示意如图2所示。
步骤3:提供性能数据HTTP调用接口,把获取集群性能的函数封装成一个HTTP接口,并且这个HTTP接口供外部调用并提供容错的处理;
步骤3.1:利用Spring MVC框架,把获取集群性能的函数封装成一个HTTP接口,这个接口返回一个Json字符串,供集群或者其他系统调用并解析出CPU利用率,内存利用率,总的内存大小,从而利用;
本实施例还通过Spring mvc技术,提供一个HTML页面,利用Echart可视化组件,为用户提供实时集群的CPU、内存、总的内存可视化数据。并可以切换到各个节点观察。通过访问性能监控数据可视化Http接口,完整的性能展示图如图7所示。
步骤3.2:采用在本地内存里面缓存最近的性能数据的方法,当出现网络延迟或者错误的时候,直接返回缓存的数据。
步骤4:利用步骤3调用的性能数据作为参考依据,采用自适应任务调度器进行任务调度。
步骤4.1:通过HTTP调用性能函数获取到性能数据,根据从Slave节点发送过来的性能监控数据,按照CPU利用率:内存利用率=9:1的比例,计算每个节点的权重,公式如下:
Weight=PCPU*0.9+PMemory*0.1
其中,PCPU为CPU利用率,PMemory为内存利用率,Weight为节点权重;
步骤4.2:初始化任务分配,调度器根据步骤4.1得到的权重大小,根据权重大小分配这个选中节点的Slot给Task;
步骤4.3:采用平滑加权轮询任务调度算法,使得权重大的节点被选中的次数不变,但是它被选中的时机分布均匀,而不是连续多次选中,其流程如图3所示;
步骤4.3.1:初始化当前权重,令当前权重等于权利要求6步骤4.1所述每个节点的权重;初始化有效权重effectiveWeight等于权利要求6步骤4.1所述每个节点的权重,初始化变量tw=0;
步骤4.3.2:将当前节点的当前权重currentWeight,用变量instance记录;
步骤4.3.3:判断是否遍历完所有节点,如果是则执行步骤4.3.6;如果不是则判断下一个节点的当前权重currentWeight是否大于instance,并执行步骤4.3.4;
步骤4.3.4:如果是则用该节点的当前权重currentWeight更新instance,再执行步骤4.3.5;否则直接执行步骤4.3.5;;
步骤4.3.5:将步骤4.3.4所述节点的有效权重effectiveWeight加上变量tw的值,并将该节点的当前权重currentWeight加上有效权重effectiveWeight重新构成该节点的当前权重currentWeight,转至执行步骤4.3.3;
步骤4.3.6:把最大的当前权重currentWeight的值的减去所有节点的权重之和,降低instance的currentWeight,并返回这个instance节点作为选中节点。
本实施例上述算法演示如图8,Weight(slave1):Weight(slave2):Weight(slave3)=3:1:2,6次调度选中的节点依次为slave1、slave3、slave1、slave2、slave1、slave3。这样的调度策略,既考虑了节点的权重,又考虑能够使调度相对平滑,避免权重大的节点一直被选中,造成负载过重,从而很快达到集群设定阈值。
步骤4.4:在中间运行过程中,如果达到集群设定资源阈值,则启用基于蚁群算法的负载均衡算法,根据集群的实时资源数据,在一定的迭代次数内,为任务集合中的每个任务选择一个最佳的分配方案,使得整个集群的运行状态处于最佳状态,相应的计算时间也相应的减少,其流程如图4所示。
步骤4.4.1:把将要参与调度的任务集合赋值给tasks[i];将每个节点的CPU利用率、内存利用率等性能数据按照9:1的比例复制给nodes[i];初始化蚂蚁的数量antcount,迭代次数iteratorNum,初始化信息素浓度矩阵,将信息素浓度矩阵pheromoneMatrix[i][j]中所有元素置为1,pheromoneMatrix矩阵的每一行中最大信息素浓度的下标记为maxPheromoneMatrix,采用随机分配策略的蚂蚁的临界编号记为criticalPointMatrix;
其中,tasks[i]表示任务i的规模,这里用任务处理的数据集大小来初始化tasks;nodes[i]表示节点i的处理性能;pheromoneMatrix[i][j]表示将任务i分配给节点j这条路径的信息素浓度;
步骤4.4.2:遍历每个任务、每个节点,计算任务执行时间数组timeMatrix[i][j];
其中,timeMatrix[i][j]表示任务i分配给节点j所需的时间;
步骤4.4.3:迭代搜索过程:
步骤4.4.3.1:初始化一个三维数组pathMatrix_allAnt,用以保存每次迭代过程中所有蚂蚁的路径;初始化一个二维数组pathMatrix_oneAnt,用以保存单只蚂蚁分配的路径,并将pathMatrix_oneAnt加入到pathMatrix_allAnt中保存;
步骤4.4.3.2:任务分配assignOneTask,任务分配函数负责将一个指定的任务按照分配策略分配给某一节点处理:
其中,分配策略有以下两种:
(1)按信息素浓度分配,将任务分配给本行中信息素浓度最高的节点pheromoneMatrix[taskCount]处理;
(2)随机分配,将任务随意分配给随机一个节点处理;
以上两种策略是根据人为设置的蚂蚁的临界编号criticalPointMatrix区间进行分类选择的;
例如criticalPointMatrix[i]=5表示0-5号蚂蚁在分配第i个任务的时候,按照第一种策略即按信息素浓度分配,而5-maxAnt将按照第二种策略即随机选择一个节点分配第i个任务。之所以需要两种策略,主要是为了寻找更优解,如果每只蚂蚁都将任务分配给信息素浓度最高的节点处理,那么就会出现停滞现象。也就是算法过早地收敛至一个局部最优解,无法发现全局最优解。因此需要一部分蚂蚁遵循信息素最高的分配策略,还需要一部分蚂蚁遵循随机分配的策略,以发现新的局部最优解。
将任务分配后的路径结果保存到数组pathMatrix_allAnt和数组pathMatrix_oneAnt中;
步骤4.4.3.3:计算每只蚂蚁的实际任务处理时间;
每迭代完一次,都要计算每只蚂蚁分配的所有任务的完成时间,即所有节点任务完成时间的最大值;
步骤4.4.3.4:更新信息素浓度矩阵pheromoneMatrix[i][j]:
模拟信息素的挥发,将所有信息素浓度降低p%;
找出本次迭代中最短路径,并将该条路径的信息素浓度提高q%;
步骤4.4.3.5:找出pheromoneMatrix[i][j]中每一行中最大信息素浓度,更新maxPheromoneMatrix数组;
步骤4.4.3.5:更新criticalPointMatrix数组:
①计算最大信息素的概率,计算方式如下:
②计算蚂蚁的临界下标,用上一步计算的maxphe乘以蚂蚁的数量,计算方式如下:
indexbound=maxphe*antcount
确定tasks[i]的临界下标indexbound,在indexbound之前的蚂蚁选择最大信息素的节点,在indexbound之后的蚂蚁选择一个随机节点,其中indexbound是criticalPointMatrix中的一个元素;
步骤4.4.3.6:重复执行步骤4.4.3.2至步骤4.4.3.5,直到迭代次数超过迭代次数iteratorNum,跳出循环;
步骤4.4.4:根据步骤4.4.3.3计算的每次迭代后,每只蚂蚁的实际任务处理时间就可以计算每次迭代用时最短的蚂蚁,再取出所有迭代中用时最短的蚂蚁,这只蚂蚁所对应任务分配方案就是全局的最优任务分配方案,即按这个方案分配任务给对应的节点,总体所用的时间最短。
Claims (8)
1.一种自适应任务调度器,其特征在于包括:性能监控数据采集模块、平滑加权轮询任务调度模块以及基于蚁群算法的任务调度模块;
所述性能监控数据采集模块包括:节点CPU利用率监控数据采集单元、节点内存利用率监控数据采集单元、监控数据上传单元、监控数据存储单元和API接口开放单元;
所述节点CPU利用率监控数据采集单元通过计算空闲时间周期和总的时钟周期来计算CPU利用率;
所述节点内存利用率监控数据采集单元通过计算空闲的内存空间和总的内存空间来计算内存利用率;
所述监控数据上传单元通过使用Netty网络通信框架,将每个集群中Slave节点的CPU利用率和内存利用率上传给集群中Master节点;
所述监控数据存储单元使用Redis内存KV数据库存储性能数据,并配置LRU的模式,保存最近的数据,能够加快监控数据的访问;
所述API接口开放单元通过使用Web技术,开放出Http的接口,供集群通过HttpClient调用;
所述平滑加权轮询任务调度模块用于在初始调度时采用平滑轮询任务调度算法达到集群负载均衡;
所述基于蚁群算法的任务调度模块用于当集群中整体资源使用达到规定阈值时,计算出全局最优任务分配方案供后续的任务分配使用,当集群资源降到阈值以下,则继续采用所述平滑加权轮询任务调度算法对任务进行分配。
2.采用权利要求1所述的自适应任务调度器进行任务调度的方法,其特征在于包括如下步骤:
步骤1:获取CPU利用率、内存利用率、总内存大小以及上传性能数据;
步骤2:在Master节点持久化Slave节点传递过来的性能数据以及Master自身的性能数据,并且配置缓存淘汰策略,清理过时的数据;
步骤3:提供性能数据HTTP调用接口,把获取集群性能的函数封装成一个HTTP接口,并且这个HTTP接口供外部调用并提供容错的处理;
步骤4:利用步骤3调用的性能数据作为参考依据,采用自适应任务调度器进行任务调度。
3.根据权利要求2所述的自适应任务调度器进行任务调度的方法,其特征在于所述步骤1的过程如下:
步骤1.1:Linux的实时性能监控数据存放在/proc文件夹下的性能记录文件里;
步骤1.2:用正则表达式去解析步骤1.1所述文件夹下对应空闲的时钟周期idleCPU、总的时钟周期totalCPU,利用idleCPU与totalCPU的比值即可得到CPU利用率;
步骤1.3:用正则表达式去解析步骤1.1所述文件夹下的空闲内存idleMem、总内存totalMem,利用idleMem与totalMem的比值即可得到内存利用率;
步骤1.4:利用Netty高性能NIO框架在每个Slave节点和Master节点建立Socket连接;
步骤1.5:Master节点向Slave节点发送Hello消息,表示Master节点希望能获取到Salve节点的性能数据;
步骤1.6:Slave节点收到Hello消息后,上传自己的性能数据给Master节点,于此同时,Slave节点与Master节点保持心跳联系,避免建立的连接关闭。
4.根据权利要求2所述的自适应任务调度器进行任务调度的方法,其特征在于所述步骤2的过程如下:
步骤2.1:Master节点开启一个定时任务,获取到自身的CPU利用率、内存利用率,并保持与Slave节点的发送时间周期一致;
步骤2.2:Master节点反序列化从Slave节点传输过来的数据,并为每个Slave节点构建一个List存放到Redis里面;
步骤2.3:为了避免数据的冗余造成Redis压力大,为Reids配置LRU的缓存淘汰策略,清理过时的数据。
5.根据权利要求2所述的自适应任务调度器进行任务调度的方法,其特征在于所述步骤3的过程如下:
步骤3.1:利用Spring MVC框架,把获取集群性能的函数封装成一个HTTP接口,这个接口返回一个Json字符串,供集群或者其他系统调用并解析出数据从而利用;
步骤3.2:采用在本地内存里面缓存最近的性能数据的方法,当出现网络延迟或者错误的时候,直接返回缓存的数据。
6.根据权利要求2所述的自适应任务调度器进行任务调度的方法,其特征在于所述步骤4的过程如下:
步骤4.1:通过HTTP调用性能函数获取到性能数据,根据从Slave节点发送过来的性能监控数据,按照CPU利用率:内存利用率=9:1的比例,计算每个节点的权重,公式如下:
Weight=PCPU*0.9+PMemory*0.1
其中,PCPU为CPU利用率,PMemory为内存利用率,Weight为节点权重;
步骤4.2:初始化任务分配,调度器根据步骤4.1得到的权重大小,根据权重大小分配这个选中节点的Slot给Task;
步骤4.3:采用平滑加权轮询任务调度算法,使得权重大的节点被选中的次数不变,但是它被选中的时机分布均匀,而不是连续多次选中;
步骤4.4:在中间运行过程中,如果达到集群设定资源阈值,则启用基于蚁群算法的负载均衡算法,根据集群的实时资源数据,在一定的迭代次数内,为任务集合中的每个任务选择一个最佳的分配方案,使得整个集群的运行状态处于最佳状态,相应的计算时间也相应的减少。
7.根据权利要求2所述的自适应任务调度器进行任务调度的方法,其特征在于所述步骤4.3的过程如下:
步骤4.3.1:初始化当前权重,令当前权重等于权利要求6步骤4.1所述每个节点的权重;初始化有效权重effectiveWeight等于权利要求6步骤4.1所述每个节点的权重,初始化变量tw=0;
步骤4.3.2:将当前节点的当前权重currentWeight,用变量instance记录;
步骤4.3.3:判断是否遍历完所有节点,如果是则执行步骤4.3.6;如果不是则判断下一个节点的当前权重currentWeight是否大于instance,并执行步骤4.3.4;
步骤4.3.4:如果是则用该节点的当前权重currentWeight更新instance,再执行步骤4.3.5;否则直接执行步骤4.3.5;;
步骤4.3.5:将步骤4.3.4所述节点的有效权重effectiveWeight加上变量tw的值,并将该节点的当前权重currentWeight加上有效权重effectiveWeight重新构成该节点的当前权重currentWeight,转至执行步骤4.3.3;
步骤4.3.6:把最大的当前权重currentWeight的值的减去所有节点的权重之和,降低instance的currentWeight,并返回这个instance节点作为选中节点。
8.根据权利要求2所述的自适应任务调度器进行任务调度的方法,其特征在于所述步骤4.4的过程如下:
步骤4.4.1:把将要参与调度的任务集合赋值给tasks[i];将每个节点的CPU利用率、内存利用率等性能数据按照9:1的比例复制给nodes[i];初始化蚂蚁的数量antcount,迭代次数iteratorNum,初始化信息素浓度矩阵,将信息素浓度矩阵pheromoneMatrix[i][j]中所有元素置为1,pheromoneMatrix矩阵的每一行中最大信息素浓度的下标记为maxPheromoneMatrix,采用随机分配策略的蚂蚁的临界编号记为criticalPointMatrix;
其中,tasks[i]表示任务i的规模,这里用任务处理的数据集大小来初始化tasks;nodes[i]表示节点i的处理性能;pheromoneMatrix[i][j]表示将任务i分配给节点j这条路径的信息素浓度;
步骤4.4.2:遍历每个任务、每个节点,计算任务执行时间数组timeMatrix[i][j];
其中,timeMatrix[i][j]表示任务i分配给节点j所需的时间;
步骤4.4.3:迭代搜索过程:
步骤4.4.3.1:初始化一个三维数组pathMatrix_allAnt,用以保存每次迭代过程中所有蚂蚁的路径;初始化一个二维数组pathMatrix_oneAnt,用以保存单只蚂蚁分配的路径,并将pathMatrix_oneAnt加入到pathMatrix_allAnt中保存;
步骤4.4.3.2:任务分配assignOneTask,任务分配函数负责将一个指定的任务按照分配策略分配给某一节点处理:
其中,分配策略有以下两种:
(1)按信息素浓度分配,将任务分配给本行中信息素浓度最高的节点pheromoneMatrix[taskCount]处理;
(2)随机分配,将任务随意分配给随机一个节点处理;
以上两种策略是根据人为设置的蚂蚁的临界编号criticalPointMatrix区间进行分类选择的;
将任务分配后的路径结果保存到数组pathMatrix_allAnt和数组pathMatrix_oneAnt中;
步骤4.4.3.3:计算每只蚂蚁的实际任务处理时间;
每迭代完一次,都要计算每只蚂蚁分配的所有任务的完成时间,即所有节点任务完成时间的最大值;
步骤4.4.3.4:更新信息素浓度矩阵pheromoneMatrix[i][j]:
模拟信息素的挥发,将所有信息素浓度降低p%;
找出本次迭代中最短路径,并将该条路径的信息素浓度提高q%;
步骤4.4.3.5:找出pheromoneMatrix[i][j]中每一行中最大信息素浓度,更新maxPheromoneMatrix数组;
步骤4.4.3.5:更新criticalPointMatrix数组:
①计算最大信息素的概率,计算方式如下:
②计算蚂蚁的临界下标,用上一步计算的max phe乘以蚂蚁的数量,计算方式如下:
indexbound=max phe*antcount
确定tasks[i]的临界下标indexbound,在indexbound之前的蚂蚁选择最大信息素的节点,在indexbound之后的蚂蚁选择一个随机节点,其中indexbound是criticalPointMatrix中的一个元素;
步骤4.4.3.6:重复执行步骤4.4.3.2至步骤4.4.3.5,直到迭代次数超过迭代次数iteratorNum,跳出循环;
步骤4.4.4:根据步骤4.4.3.3计算的每次迭代后,每只蚂蚁的实际任务处理时间就可以计算每次迭代用时最短的蚂蚁,再取出所有迭代中用时最短的蚂蚁,这只蚂蚁所对应任务分配方案就是全局的最优任务分配方案,即按这个方案分配任务给对应的节点,总体所用的时间最短。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201911021198.0A CN110764912B (zh) | 2019-10-25 | 2019-10-25 | 一种自适应任务调度器及方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201911021198.0A CN110764912B (zh) | 2019-10-25 | 2019-10-25 | 一种自适应任务调度器及方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN110764912A true CN110764912A (zh) | 2020-02-07 |
CN110764912B CN110764912B (zh) | 2022-09-09 |
Family
ID=69333824
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201911021198.0A Active CN110764912B (zh) | 2019-10-25 | 2019-10-25 | 一种自适应任务调度器及方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN110764912B (zh) |
Cited By (18)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111427632A (zh) * | 2020-02-23 | 2020-07-17 | 西北师范大学 | 针对成瘾人员的心理测评方法及其系统框架的运行方法 |
CN111432012A (zh) * | 2020-03-30 | 2020-07-17 | 浙江每日互动网络科技股份有限公司 | 异步通信方法及装置、系统、终端和计算机可读存储介质 |
CN111459680A (zh) * | 2020-04-07 | 2020-07-28 | 周文明 | 一种数据采集处理系统和方法 |
CN111614377A (zh) * | 2020-04-24 | 2020-09-01 | 江苏方天电力技术有限公司 | 一种基于hplc并发通道的采集多任务调度方法和系统 |
CN111629046A (zh) * | 2020-05-22 | 2020-09-04 | 中国联合网络通信集团有限公司 | 边缘计算协同方法、边缘计算设备及终端 |
CN111737001A (zh) * | 2020-06-24 | 2020-10-02 | 国网电力科学研究院有限公司 | 一种计算系统负载均衡方法、装置及存储介质 |
CN111813513A (zh) * | 2020-06-24 | 2020-10-23 | 中国平安人寿保险股份有限公司 | 基于分布式的实时任务调度方法、装置、设备及介质 |
CN111935090A (zh) * | 2020-07-07 | 2020-11-13 | 上海微亿智造科技有限公司 | 工业智造物联网的大数据传输和持久化方法及系统 |
CN112187670A (zh) * | 2020-08-21 | 2021-01-05 | 西安电子科技大学 | 一种基于群体智能的网络化软件共享资源分配方法及装置 |
CN112395318A (zh) * | 2020-11-24 | 2021-02-23 | 福州大学 | 一种基于HBase+Redis的分布式存储中间件 |
CN112416530A (zh) * | 2020-12-08 | 2021-02-26 | 西藏宁算科技集团有限公司 | 弹性管理集群物理机节点的方法、装置及电子设备 |
CN112700160A (zh) * | 2021-01-12 | 2021-04-23 | 上海观察者信息技术有限公司 | 任务分配方法、装置及计算机可读存储介质 |
CN112769946A (zh) * | 2021-01-19 | 2021-05-07 | 上海七牛信息技术有限公司 | 一种在rtc网络中对合流任务动态均衡调度方法及系统 |
CN113255165A (zh) * | 2021-06-28 | 2021-08-13 | 中国人民解放军国防科技大学 | 一种基于动态任务分配的实验方案并行推演系统 |
CN113608878A (zh) * | 2021-08-18 | 2021-11-05 | 上海德拓信息技术股份有限公司 | 一种基于资源权重计算的任务分布式调度方法与系统 |
CN113901141A (zh) * | 2021-10-11 | 2022-01-07 | 京信数据科技有限公司 | 一种分布式数据同步方法及系统 |
CN113961320A (zh) * | 2021-09-16 | 2022-01-21 | 大连华锐重工集团股份有限公司 | 一种自适应增益集群调度控制方法 |
CN114780247A (zh) * | 2022-05-17 | 2022-07-22 | 中国地质大学(北京) | 一种流速和资源感知的流应用调度方法及系统 |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103970609A (zh) * | 2014-04-24 | 2014-08-06 | 南京信息工程大学 | 一种基于改进蚁群算法的云数据中心任务调度方法 |
US20170017521A1 (en) * | 2015-07-13 | 2017-01-19 | Palo Alto Research Center Incorporated | Dynamically adaptive, resource aware system and method for scheduling |
CN106844027A (zh) * | 2017-01-13 | 2017-06-13 | 广西电网有限责任公司电力科学研究院 | 一种基于节点负载的任务调度方法 |
CN106951059A (zh) * | 2017-03-28 | 2017-07-14 | 中国石油大学(华东) | 基于dvs与改进蚁群算法的云数据中心节能方法 |
CN108874528A (zh) * | 2017-05-09 | 2018-11-23 | 北京京东尚科信息技术有限公司 | 分布式任务存储系统和分布式任务存储/读取方法 |
CN109711526A (zh) * | 2018-12-20 | 2019-05-03 | 广东工业大学 | 基于svm和蚁群算法的服务器集群调度方法 |
-
2019
- 2019-10-25 CN CN201911021198.0A patent/CN110764912B/zh active Active
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103970609A (zh) * | 2014-04-24 | 2014-08-06 | 南京信息工程大学 | 一种基于改进蚁群算法的云数据中心任务调度方法 |
US20170017521A1 (en) * | 2015-07-13 | 2017-01-19 | Palo Alto Research Center Incorporated | Dynamically adaptive, resource aware system and method for scheduling |
CN106844027A (zh) * | 2017-01-13 | 2017-06-13 | 广西电网有限责任公司电力科学研究院 | 一种基于节点负载的任务调度方法 |
CN106951059A (zh) * | 2017-03-28 | 2017-07-14 | 中国石油大学(华东) | 基于dvs与改进蚁群算法的云数据中心节能方法 |
CN108874528A (zh) * | 2017-05-09 | 2018-11-23 | 北京京东尚科信息技术有限公司 | 分布式任务存储系统和分布式任务存储/读取方法 |
CN109711526A (zh) * | 2018-12-20 | 2019-05-03 | 广东工业大学 | 基于svm和蚁群算法的服务器集群调度方法 |
Non-Patent Citations (1)
Title |
---|
赵梦等: "云计算环境下基于蚁群优化的任务负载均衡调度算法", 《电子设计工程》 * |
Cited By (24)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111427632A (zh) * | 2020-02-23 | 2020-07-17 | 西北师范大学 | 针对成瘾人员的心理测评方法及其系统框架的运行方法 |
CN111432012A (zh) * | 2020-03-30 | 2020-07-17 | 浙江每日互动网络科技股份有限公司 | 异步通信方法及装置、系统、终端和计算机可读存储介质 |
CN111459680A (zh) * | 2020-04-07 | 2020-07-28 | 周文明 | 一种数据采集处理系统和方法 |
CN111614377B (zh) * | 2020-04-24 | 2021-09-14 | 江苏方天电力技术有限公司 | 一种基于hplc并发通道的采集多任务调度方法和系统 |
CN111614377A (zh) * | 2020-04-24 | 2020-09-01 | 江苏方天电力技术有限公司 | 一种基于hplc并发通道的采集多任务调度方法和系统 |
CN111629046A (zh) * | 2020-05-22 | 2020-09-04 | 中国联合网络通信集团有限公司 | 边缘计算协同方法、边缘计算设备及终端 |
CN111629046B (zh) * | 2020-05-22 | 2022-04-08 | 中国联合网络通信集团有限公司 | 边缘计算协同方法、边缘计算设备及终端 |
CN111813513A (zh) * | 2020-06-24 | 2020-10-23 | 中国平安人寿保险股份有限公司 | 基于分布式的实时任务调度方法、装置、设备及介质 |
CN111813513B (zh) * | 2020-06-24 | 2024-05-14 | 中国平安人寿保险股份有限公司 | 基于分布式的实时任务调度方法、装置、设备及介质 |
CN111737001A (zh) * | 2020-06-24 | 2020-10-02 | 国网电力科学研究院有限公司 | 一种计算系统负载均衡方法、装置及存储介质 |
CN111935090A (zh) * | 2020-07-07 | 2020-11-13 | 上海微亿智造科技有限公司 | 工业智造物联网的大数据传输和持久化方法及系统 |
CN112187670A (zh) * | 2020-08-21 | 2021-01-05 | 西安电子科技大学 | 一种基于群体智能的网络化软件共享资源分配方法及装置 |
CN112395318A (zh) * | 2020-11-24 | 2021-02-23 | 福州大学 | 一种基于HBase+Redis的分布式存储中间件 |
CN112416530A (zh) * | 2020-12-08 | 2021-02-26 | 西藏宁算科技集团有限公司 | 弹性管理集群物理机节点的方法、装置及电子设备 |
CN112416530B (zh) * | 2020-12-08 | 2023-12-22 | 西藏宁算科技集团有限公司 | 弹性管理集群物理机节点的方法、装置及电子设备 |
CN112700160A (zh) * | 2021-01-12 | 2021-04-23 | 上海观察者信息技术有限公司 | 任务分配方法、装置及计算机可读存储介质 |
CN112769946A (zh) * | 2021-01-19 | 2021-05-07 | 上海七牛信息技术有限公司 | 一种在rtc网络中对合流任务动态均衡调度方法及系统 |
CN112769946B (zh) * | 2021-01-19 | 2023-04-07 | 上海七牛信息技术有限公司 | 一种在rtc网络中对合流任务动态均衡调度方法及系统 |
CN113255165A (zh) * | 2021-06-28 | 2021-08-13 | 中国人民解放军国防科技大学 | 一种基于动态任务分配的实验方案并行推演系统 |
CN113608878A (zh) * | 2021-08-18 | 2021-11-05 | 上海德拓信息技术股份有限公司 | 一种基于资源权重计算的任务分布式调度方法与系统 |
CN113961320A (zh) * | 2021-09-16 | 2022-01-21 | 大连华锐重工集团股份有限公司 | 一种自适应增益集群调度控制方法 |
CN113901141A (zh) * | 2021-10-11 | 2022-01-07 | 京信数据科技有限公司 | 一种分布式数据同步方法及系统 |
CN114780247B (zh) * | 2022-05-17 | 2022-12-13 | 中国地质大学(北京) | 一种流速和资源感知的流应用调度方法及系统 |
CN114780247A (zh) * | 2022-05-17 | 2022-07-22 | 中国地质大学(北京) | 一种流速和资源感知的流应用调度方法及系统 |
Also Published As
Publication number | Publication date |
---|---|
CN110764912B (zh) | 2022-09-09 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN110764912B (zh) | 一种自适应任务调度器及方法 | |
US10055262B1 (en) | Distributed load balancing with imperfect workload information | |
CN105491138B (zh) | 一种基于负载率分级触发的分布式负载调度方法 | |
CN110383764B (zh) | 无服务器系统中使用历史数据处理事件的系统和方法 | |
Yao et al. | Load balancing strategy of cloud computing based on artificial bee algorithm | |
CN103176849B (zh) | 一种基于资源分类的虚拟机集群的部署方法 | |
CN112737823A (zh) | 一种资源切片分配方法、装置及计算机设备 | |
Liu et al. | Task scheduling in fog enabled Internet of Things for smart cities | |
CN107566535B (zh) | 基于Web地图服务并发访问时序规则的自适应负载均衡方法 | |
CN103607424B (zh) | 一种服务器连接方法及服务器系统 | |
CN110221920B (zh) | 部署方法、装置、存储介质及系统 | |
Evans et al. | Dynamic load balancing using task-transfer probabilities | |
CN111865817A (zh) | 遥测采集器负载均衡管控方法、装置、设备及存储介质 | |
CN111143036A (zh) | 一种基于强化学习的虚拟机资源调度方法 | |
JP2005148911A (ja) | 負荷分散方法及び装置とシステム並びにプログラム | |
CN110198267A (zh) | 一种流量调度方法、系统及服务器 | |
CN117076133B (zh) | 云游戏平台异构资源分配方法、计算机装置及存储介质 | |
CN108667920B (zh) | 一种雾计算环境业务流量加速系统及其业务流量加速方法 | |
Birke et al. | Meeting latency target in transient burst: A case on spark streaming | |
Maassen et al. | Middleware adaptation with the delphoi service | |
CN115988075A (zh) | 一种基于人工鱼群算法的云数据迁移方法及装置 | |
Weissman et al. | The Virtual Service Grid: an architecture for delivering high‐end network services | |
Raj et al. | Load balancing for resource provisioning using batch mode heuristic priority in round robin (pbrr) scheduling | |
CN110971647A (zh) | 一种大数据系统的节点迁移方法 | |
Alharbi et al. | Optimizing jobs' completion time in cloud systems during virtual machine placement |
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 | ||
GR01 | Patent grant | ||
GR01 | Patent grant |