CN112463349A - 一种高效调度gpu能力的负载均衡方法及*** - Google Patents
一种高效调度gpu能力的负载均衡方法及*** Download PDFInfo
- Publication number
- CN112463349A CN112463349A CN202110116747.3A CN202110116747A CN112463349A CN 112463349 A CN112463349 A CN 112463349A CN 202110116747 A CN202110116747 A CN 202110116747A CN 112463349 A CN112463349 A CN 112463349A
- Authority
- CN
- China
- Prior art keywords
- gpu
- process group
- target process
- screening
- video memory
- 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
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/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/5083—Techniques for rebalancing the load in a distributed system
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer And Data Communications (AREA)
Abstract
本发明公开了一种高效调度GPU能力的负载均衡方法及***,方法包括以下步骤:查询所有GPU卡的数量以及每张所述GPU卡的显存;根据目标进程组申请的显存大小进行初步筛选,筛选出可用显存资源满足该目标进程组申请的节点;进行二次筛选,从所述节点中筛选出可用显存资源满足该目标进程组申请的GPU卡;进行三次筛选,从所述GPU卡中筛选出可用显存资源最少的GPU卡,并将所述GPU卡所在的节点与所述目标进程组进行绑定;在与所述目标进程组绑定的所述节点上创建所述目标进程组。本发明的有益效果:可让使用者通过API描述来实现对一个可共享资源的申请,并能实现该种资源的调度,从而可使任务调度更加合理高效,提高了GPU的利用率。
Description
技术领域
本发明涉及负载均衡的技术领域,具体来说,涉及一种高效调度GPU能力的负载均衡方法及***。
背景技术
负载均衡策略是互联网开发运营过程中经常遇到的一类问题。负载均衡建立在现有网络结构之上,它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。通过调用***函数将图片识别请求进行转换,得到识别任务,并将识别任务放入任务队列,任务队列用于缓存识别任务;通过while循环从任务队列中取出当前识别任务;通过调用***API函数获取***GPU的数量;通过调用***API函数GPU_GetUsages获取各***GPU的使用率;根据各***GPU的使用率,确定使用率最小的***GPU,并将当前识别任务分配给使用率最小的***GPU执行。
全球主要的容器集群服务厂商的容器集群管理***(Kubernetes)服务都提供了Nvidia GPU容器调度能力,但是通常都是将一个GPU卡分配给一个容器。这可以实现比较好的隔离性,确保使用GPU的应用不会被其他应用影响;对于深度学习模型训练的场景非常适合,但是如果对于模型开发和模型预测的场景就会比较浪费。大家的诉求是能够让更多的预测服务共享同一个GPU卡上,进而提高集群中Nvidia GPU的利用率。而这就需要提供GPU资源的划分,而这里GPU资源划分的维度指的就是GPU显存和Cuda Kernel线程的划分。
GPU共享,是指在同一张GPU卡上同时运行多个任务。GPU共享应用在集群中可以运行更多任务,减少抢占。GPU共享后,总利用率接近运行任务利用率之和,减少了资源浪费。GPU共享后可以增强公平性,因为多个任务可以同时开始享受资源;也可以单独保证某一个任务的QoS;可减少任务排队时间;使总任务结束时间下降;假设两个任务结束时间分别是x,y,通过GPU共享,两个任务全部结束的时间小于x+y。
通常在集群级别谈支持共享GPU指的是两件事情:一是调度,二是隔离,对于细粒度的GPU卡调度而言,目前容器集群服务厂商并没有很好的方案,这是由于容器集群管理***对于GPU这类扩展资源的定义仅仅支持整数粒度的加加减减,无法支持复杂资源的分配。比如用户希望使用进程组(Pod)A占用半张GPU卡,这在目前容器集群管理***的架构设计中是无法实现的,更不用多GPU卡的共享。
针对相关技术中的问题,目前尚未提出有效的解决方案。
发明内容
针对相关技术中的上述技术问题,本发明提出一种高效调度GPU能力的负载均衡方法,可让使用者通过API描述来实现对一个可共享资源的申请,并能实现该种资源的调度。
为实现上述技术目的,本发明的技术方案是这样实现的:
一种高效调度GPU能力的负载均衡方法,包括以下步骤:
S1查询所有GPU卡的数量以及每张所述GPU卡的显存;
S2根据目标进程组申请的显存大小进行初步筛选,筛选出可用显存资源满足该目标进程组申请的节点;
S3进行二次筛选,从所述节点中筛选出可用显存资源满足该目标进程组申请的GPU卡;
S4进行三次筛选,从所述GPU卡中筛选出可用显存资源最少的GPU卡,并将所述GPU卡所在的节点与所述目标进程组进行绑定;
S5在与所述目标进程组绑定的所述节点上创建所述目标进程组。
进一步地,在S1中,GPU共享设备插件通过nvml库查询所述GPU卡的数量以及所述GPU卡的显存。
进一步地,在S2中,容器集群管理***通过全局调度器进行初步筛选。
进一步地,在S3中,所述全局调度器通过所述GPU共享调度器扩展组件进行二次筛选。
进一步地,在S4中,所述GPU共享调度器扩展组件进行三次筛选,所述GPU共享调度器扩展组件通过API 服务器将所述节点与所述进程进行绑定。
进一步地,在S5中,通过运行在与所述目标进程组绑定的所述节点上的代理来创建所述目标进程组。
进一步地,在S5中,在创建所述目标进程组时,首先会列出该节点中所有状态为等待并且未创建所述目标进程组的GPU共享进程组,然后选择出进程数量与所述目标进程组的进程数量一致的所述GPU共享进程组,若有多个符合这种条件的所述GPU共享进程组,则选择其中指定时间最早的所述GPU共享进程组;最后将所述GPU共享进程组的GPU信息转化为环境变量返回给所述代理用以创建所述目标进程组。
本发明还提供了一种高效调度GPU能力的负载均衡***,包括:
GPU共享设备插件,用于查询所有GPU卡的数量以及每张所述GPU卡的显存;
全局调度器,用于进行初步筛选,筛选出可用显存资源满足目标进程组申请的显存大小的节点;
GPU共享调度器扩展组件,用于进行二次筛选和三次筛选,所述二次筛选用于从所述节点中筛选出可用显存资源满足该目标进程组申请的GPU卡,所述三次筛选用于从所述GPU卡中筛选出可用显存资源最少的GPU卡;
API 服务器,用于将通过所述三次筛选筛选出的所述GPU卡所在的节点与所述目标进程组进行绑定;
代理,用于在与所述目标进程组绑定的所述节点上创建所述目标进程组。
进一步地,所述GPU共享设备插件通过nvml库查询所述GPU卡的数量以及所述GPU卡的显存。
进一步地,在创建所述目标进程组时,首先会列出该节点中所有状态为等待并且未创建所述目标进程组的GPU共享进程组,然后选择出进程数量与所述目标进程组的进程数量一致的所述GPU共享进程组,若有多个符合这种条件的所述GPU共享进程组,则选择其中指定时间最早的所述GPU共享进程组;最后将所述GPU共享进程组的GPU信息转化为环境变量返回给所述代理用以创建所述目标进程组。
本发明的有益效果:可让使用者通过API描述来实现对一个可共享资源的申请,并能实现该种资源的调度,从而可使任务调度更加合理高效,提高了GPU的利用率。
具体实施方式
下面将对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员所获得的所有其他实施例,都属于本发明保护的范围。
根据本发明实施例所述的一种高效调度GPU能力的负载均衡方法,包括以下步骤:
S1查询所有GPU卡的数量以及每张所述GPU卡的显存;
S2根据目标进程组申请的显存大小进行初步筛选,筛选出可用显存资源满足该目标进程组申请的节点;
S3进行二次筛选,从所述节点中筛选出可用显存资源满足该目标进程组申请的GPU卡;
S4进行三次筛选,从所述GPU卡中筛选出可用显存资源最少的GPU卡,并将所述GPU卡所在的节点与所述目标进程组进行绑定;
S5在与所述目标进程组绑定的所述节点上创建所述目标进程组。
在本发明的一个具体实施例中,在S1中,GPU共享设备插件通过nvml库查询所述GPU卡的数量以及所述GPU卡的显存。
在本发明的一个具体实施例中,在S2中,容器集群管理***通过全局调度器进行初步筛选。
在本发明的一个具体实施例中,在S3中,所述全局调度器通过所述GPU共享调度器扩展组件进行二次筛选。
在本发明的一个具体实施例中,在S4中,所述GPU共享调度器扩展组件进行三次筛选,所述GPU共享调度器扩展组件通过API 服务器将所述节点与所述进程进行绑定。
在本发明的一个具体实施例中,在S5中,通过运行在与所述目标进程组绑定的所述节点上的代理来创建所述目标进程组。
在本发明的一个具体实施例中,在S5中,在创建所述目标进程组时,首先会列出该节点中所有状态为等待并且未创建所述目标进程组的GPU共享进程组,然后选择出进程数量与所述目标进程组的进程数量一致的所述GPU共享进程组,若有多个符合这种条件的所述GPU共享进程组,则选择其中指定时间最早的所述GPU共享进程组;最后将所述GPU共享进程组的GPU信息转化为环境变量返回给所述代理用以创建所述目标进程组。
本发明还提供了一种高效调度GPU能力的负载均衡***,包括:
GPU共享设备插件,用于查询所有GPU卡的数量以及每张所述GPU卡的显存;
全局调度器,用于进行初步筛选,筛选出可用显存资源满足目标进程组申请的显存大小的节点;
GPU共享调度器扩展组件,用于进行二次筛选和三次筛选,所述二次筛选用于从所述节点中筛选出可用显存资源满足该目标进程组申请的GPU卡,所述三次筛选用于从所述GPU卡中筛选出可用显存资源最少的GPU卡;
API 服务器,用于将通过所述三次筛选筛选出的所述GPU卡所在的节点与所述目标进程组进行绑定;
代理,用于在与所述目标进程组绑定的所述节点上创建所述目标进程组。
在本发明的一个具体实施例中,所述GPU共享设备插件通过nvml库查询所述GPU卡的数量以及所述GPU卡的显存。
在本发明的一个具体实施例中,在创建所述目标进程组时,首先会列出该节点中所有状态为等待并且未创建所述目标进程组的GPU共享进程组,然后选择出进程数量与所述目标进程组的进程数量一致的所述GPU共享进程组,若有多个符合这种条件的所述GPU共享进程组,则选择其中指定时间最早的所述GPU共享进程组;最后将所述GPU共享进程组的GPU信息转化为环境变量返回给所述代理用以创建所述目标进程组。
为了方便理解本发明的上述技术方案,以下通过具体使用方式对本发明的上述技术方案进行详细说明。
本发明实施例所述的高效调度GPU能力的负载均衡方法不会修改容器集群管理***核心的扩展资源的设计、调度器的实现、设备插件的机制以及代理的相关设计。重用扩展资源描述共享资源的申请API。这样的好处在于提供一个可以移植的方案,用户可以在原生容器集群管理***上使用这个方案。本方法使按显存调度和按卡调度的方式在集群内并存,但是在同一个节点内是互斥的,不支持二者并存;要么是按卡数目调度,要么是按显存调度。
本方法依旧延用容器集群管理***扩展资源定义,但是衡量维度最小单位从1个GPU卡变为GPU显存的MiB。如果所节点使用的GPU为单卡16GiB显存,它对应的资源就是16276MiB。
由于用户对于共享GPU的诉求在于模型开发和模型预测场景,在此场景下,用户申请的GPU资源上限不会超过一张卡,也就是申请的资源上限为单卡,因此本方法首先是定义了两个新的扩展资源(Extended Resource): 第一个是GPU显存(GPU-Mem),第二个是GPU卡数(GPU-Count)。 通过两个标量资源描述矢量资源, 并且结合这一资源,提供支持共享GPU的工作机制。
本方法中提到的相关名词释义如下:
Kubernetes是容器集群管理***,是一个开源的平台,可以实现容器集群的自动化部署、自动扩缩容、维护等功能。
Pod是Kubernetes创建或部署的最小/最简单的基本单位,一个Pod代表集群上正在运行的一个进程组。
Kubelet是在集群中每个节点上运行的代理。它能保证容器都运行在 Pod 中。kubelet 接收一组通过各类机制提供给它的 Pod Specs,确保这些 Pod Specs 中描述的容器处于运行状态且健康。kubelet 不会管理不是由 Kubernetes 创建的容器。
kube-scheduler是主节点上的组件,该组件监视那些新创建的未指定运行节点的Pod,并选择节点让 Pod 在上面运行。调度决策考虑的因素包括单个 Pod 和 Pod 集合的资源需求、硬件/软件/策略约束、亲和性和反亲和性规范、数据位置、工作负载间的干扰和最后时限。
kube-apiserver是API 服务器的组件,该组件公开了 Kubernetes API。 API 服务器是 Kubernetes 控制面的前端。Kubernetes API 服务器的主要实现是 kube-apiserver。 kube-apiserver 设计上考虑了水平伸缩,也就是说,它可通过部署多个实例进行伸缩。可以运行 kube-apiserver 的多个实例,并在这些实例之间平衡流量。
本方法需要用到两个核心功能模块:GPU共享调度器扩展组件和GPU共享设备插件。
GPU共享调度器扩展组件(GPU Share Scheduler Extender): 利用Kubernetes的调度器扩展机制,负责在全局调度器过滤(Filter)和Bind的时候判断节点上单个GPU卡是否能够提供足够的GPU-Mem,并且在Bind的时刻将GPU的分配结果通过annotation记录到Pod Spec以供后续Filter检查分配结果。
GPU共享设备插件(GPU Share Device Plugin): 利用设备插件(Device Plugin)机制,在节点上被Kubelet调用负责GPU卡的分配,依赖scheduler Extender分配结果执行。
本方法具体流程如下:
1)资源上报。GPU共享设备插件(GPU Share Device Plugin)利用nvml库查询到GPU卡的数量和每张GPU卡的显存, 通过ListAndWatch()将节点的GPU总显存(数量*显存)作为另外的扩展资源(Extended Resource)汇报给Kubelet; Kubelet进一步汇报给KubernetesAPI Server。 举例说明,如果节点含有两块GPU卡,并且每块卡包含16276MiB,从用户的角度来看:该节点的GPU资源为16276*2 = 32552; 同时也会将节点上的GPU卡数量2作为另外一个Extended Resource上报。
2)扩展调度。GPU共享调度器扩展组件(GPU Share Scheduler Extender)可以在分配GPU-Mem给Pod的同时将分配信息以annotation的形式保留在Pod spec中,并且在过滤时刻根据此信息判断每张卡是否包含足够可用的GPU-Mem用来分配。
Kubernetes的默认调度器(即全局调度器)在进行完所有过滤(filter)行为后会通过http方式调用GPU共享调度器扩展组件(GPU Share Scheduler Extender)的进行二次筛选和三次筛选,这是由于默认调度器计算扩展资源(Extended Resource)时,只能判断资源总量是否有满足需求的空闲资源,无法具体判断单张卡上是否满足需求;所以就需要由GPU共享调度器扩展组件(GPU Share Scheduler Extender)检查单张卡上是否含有可用资源。
举例来说,在由3个包含两块GPU卡的节点组成的Kubernetes集群中,当用户发起的目标进程组申请GPU-Mem=8138时,默认调度器会扫描所有节点,发现N1所剩的资源为(16276*2-16276-12207=4069)不满足资源需求,N1节点被过滤掉。而N2和N3节点所剩资源都为8138MiB,从整体调度的角度看,都符合默认调度器的条件;此时默认调度器会委托GPU共享调度器扩展组件(GPU Share Scheduler Extender)进行二次过滤,在二次过滤中,GPU共享调度器扩展组件(GPU Share Scheduler Extender)需要判断单张卡是否满足调度需求,在查看N2节点时发现该节点虽然有8138MiB可用资源,但是落到每张卡上看,GPU0和分别GPU1只有4069MiB的可用资源,无法满足单卡8138MiB的诉求。而N3节点虽然也是总共有8138MiB可用资源,但是这些可用资源都属于GPU0,满足单卡可调度的需求。由此,通过GPU共享调度器扩展组件(GPU Share Scheduler Extender)的二次筛选和三次筛选就可以实现精准的条件筛选。
当调度器找到满足条件的节点,就会委托GPU共享调度器扩展组件(GPU ShareScheduler Extender)的bind方法进行节点和Pod的绑定,这里GPU共享调度器扩展组件需要做的是下面两件事情:
Ⅰ)以binpack的规则找到节点中最优选择的GPU卡id,此处的最优含义是对于同一个节点不同的GPU卡来说,以binpack的原则作为判断条件,优先选择空闲资源满足条件但同时又是所剩资源最少的GPU卡,并且将其作为GPU_MEM_IDX保存到Pod的annotation中;同时也保存该Pod申请的GPU Mem作为GPU_MEM_POD和GPU_MEM_ASSUME_TIME保存至Pod的annotation中,并且在此时进行Pod和所选节点的绑定。
注意:这时还会保存GPU_MEM_ASSIGNED的Pod annotation,它被初始化为“false”。它表示该Pod在调度时刻被指定到了某块GPU卡,但是并没有真正在节点上创建该Pod。GPU_MEM_ASSUME_TIME代表了指定时间。
如果此时发现分配节点上没有GPU资源符合条件,此时不进行绑定,直接不报错退出,默认调度器会在assume超时后重新调度。
Ⅱ)调用Kubernetes API执行节点和Pod的绑定。
当GPU共享调度器扩展组件(GPU Share Scheduler Extender)要把GPU-Mem=8138的Pod和经过筛选出来的节点N3绑定,首先会比较不同GPU的可用资源,分别为GPU0(12207),GPU1(8138),GPU2(4069),GPU3(16276),其中GPU2所剩资源不满足需求,被舍弃掉;而另外三个满足条件的GPU卡中, GPU1恰恰是符合空闲资源满足条件但同时又是所剩资源最少的GPU卡,因此GPU1被选出。
3)创建目标进程组。当Pod和节点绑定的事件被Kubelet接收到后,Kubelet就会在节点上创建真正的Pod实体,在这个过程中, Kubelet会调用GPU Share Device Plugin的分配(Allocate)方法, 分配方法的参数是Pod申请的GPU-Mem。而在分配方法中,会根据GPU共享调度器扩展组件(GPU Share Scheduler Extender)的调度决策运行对应的Pod
在创建目标进程组时,首先会列出该节点中所有状态为等待(Pending)并且GPU_MEM_ASSIGNED为false的GPU共享进程组(GPU Share Pod);然后选择出其中Pod Annotation的GPU_MEM_POD的数量与目标进程组的进程数量一致的GPU Share Pod。如果有多个符合这种条件的GPU Share Pod,就会选择其中PU_MEM_ASSUME_TIME最早的GPU Share Pod;最后将该GPU Share Pod annotation的GPU_MEM_ASSIGNED设置为true,并且将GPU Share Podannotation中的GPU信息转化为环境变量返回给Kubelet用以真正的创建目标进程组。
综上所述,借助于本发明的上述技术方案,可让使用者通过API描述来实现对一个可共享资源的申请,并能实现该种资源的调度,从而可使任务调度更加合理高效,提高了GPU的利用率。
以上仅为本发明的较佳实施例而已,并不用以限制本发明,凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。
Claims (10)
1.一种高效调度GPU能力的负载均衡方法,其特征在于,包括以下步骤:
S1查询所有GPU卡的数量以及每张所述GPU卡的显存;
S2根据目标进程组申请的显存大小进行初步筛选,筛选出可用显存资源满足该目标进程组申请的节点;
S3进行二次筛选,从所述节点中筛选出可用显存资源满足该目标进程组申请的GPU卡;
S4进行三次筛选,从所述GPU卡中筛选出可用显存资源最少的GPU卡,并将所述GPU卡所在的节点与所述目标进程组进行绑定;
S5在与所述目标进程组绑定的所述节点上创建所述目标进程组。
2.根据权利要求1所述的高效调度GPU能力的负载均衡方法,其特征在于,在S1中,GPU共享设备插件通过nvml库查询所述GPU卡的数量以及所述GPU卡的显存。
3.根据权利要求1所述的高效调度GPU能力的负载均衡方法,其特征在于,在S2中,容器集群管理***通过全局调度器进行初步筛选。
4.根据权利要求3所述的高效调度GPU能力的负载均衡方法,其特征在于,在S3中,所述全局调度器通过GPU共享调度器扩展组件进行二次筛选。
5.根据权利要求4所述的高效调度GPU能力的负载均衡方法,其特征在于,在S4中,所述GPU共享调度器扩展组件进行三次筛选,所述GPU共享调度器扩展组件通过API 服务器将所述节点与所述进程进行绑定。
6.根据权利要求1所述的高效调度GPU能力的负载均衡方法,其特征在于,在S5中,通过运行在与所述目标进程组绑定的所述节点上的代理来创建所述目标进程组。
7.根据权利要求6所述的高效调度GPU能力的负载均衡方法,其特征在于,在S5中,在创建所述目标进程组时,首先会列出该节点中所有状态为等待并且未创建所述目标进程组的GPU共享进程组,然后选择出进程数量与所述目标进程组的进程数量一致的所述GPU共享进程组,若有多个符合这种条件的所述GPU共享进程组,则选择其中指定时间最早的所述GPU共享进程组;最后将所述GPU共享进程组的GPU信息转化为环境变量返回给所述代理用以创建所述目标进程组。
8.一种高效调度GPU能力的负载均衡***,其特征在于,包括:
GPU共享设备插件,用于查询所有GPU卡的数量以及每张所述GPU卡的显存;
全局调度器,用于进行初步筛选,筛选出可用显存资源满足目标进程组申请的显存大小的节点;
GPU共享调度器扩展组件,用于进行二次筛选和三次筛选,所述二次筛选用于从所述节点中筛选出可用显存资源满足该目标进程组申请的GPU卡,所述三次筛选用于从所述GPU卡中筛选出可用显存资源最少的GPU卡;
API 服务器,用于将通过所述三次筛选筛选出的所述GPU卡所在的节点与所述目标进程组进行绑定;
代理,用于在与所述目标进程组绑定的所述节点上创建所述目标进程组。
9.根据权利要求8所述的高效调度GPU能力的负载均衡***,其特征在于,所述GPU共享设备插件通过nvml库查询所述GPU卡的数量以及所述GPU卡的显存。
10.根据权利要求8所述的高效调度GPU能力的负载均衡***,其特征在于,在创建所述目标进程组时,首先会列出该节点中所有状态为等待并且未创建所述目标进程组的GPU共享进程组,然后选择出进程数量与所述目标进程组的进程数量一致的所述GPU共享进程组,若有多个符合这种条件的所述GPU共享进程组,则选择其中指定时间最早的所述GPU共享进程组;最后将所述GPU共享进程组的GPU信息转化为环境变量返回给所述代理用以创建所述目标进程组。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202110116747.3A CN112463349A (zh) | 2021-01-28 | 2021-01-28 | 一种高效调度gpu能力的负载均衡方法及*** |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202110116747.3A CN112463349A (zh) | 2021-01-28 | 2021-01-28 | 一种高效调度gpu能力的负载均衡方法及*** |
Publications (1)
Publication Number | Publication Date |
---|---|
CN112463349A true CN112463349A (zh) | 2021-03-09 |
Family
ID=74802729
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202110116747.3A Pending CN112463349A (zh) | 2021-01-28 | 2021-01-28 | 一种高效调度gpu能力的负载均衡方法及*** |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN112463349A (zh) |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN113254186A (zh) * | 2021-06-15 | 2021-08-13 | 阿里云计算有限公司 | 一种进程调度方法、调度器及存储介质 |
CN113687795A (zh) * | 2021-10-25 | 2021-11-23 | 浩鲸云计算科技股份有限公司 | 一种实现有状态应用的存储卷隔离性分配的方法和*** |
CN113742064A (zh) * | 2021-08-06 | 2021-12-03 | 苏州浪潮智能科技有限公司 | 一种服务器集群的资源整理方法、***、设备及介质 |
CN113821328A (zh) * | 2021-11-23 | 2021-12-21 | 江苏苏宁银行股份有限公司 | 一种容器集群的调度方法、装置、电子设备和存储介质 |
CN113849312A (zh) * | 2021-09-29 | 2021-12-28 | 北京百度网讯科技有限公司 | 数据处理任务的分配方法、装置、电子设备及存储介质 |
CN115098238A (zh) * | 2022-07-07 | 2022-09-23 | 北京鼎成智造科技有限公司 | 一种应用程序任务调度方法及装置 |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111381957A (zh) * | 2018-12-29 | 2020-07-07 | 上海哔哩哔哩科技有限公司 | 面向分布式平台的服务实例精细化调度方法及*** |
CN112052068A (zh) * | 2020-08-17 | 2020-12-08 | 烽火通信科技股份有限公司 | 一种Kubernetes容器平台CPU绑核的方法与装置 |
-
2021
- 2021-01-28 CN CN202110116747.3A patent/CN112463349A/zh active Pending
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111381957A (zh) * | 2018-12-29 | 2020-07-07 | 上海哔哩哔哩科技有限公司 | 面向分布式平台的服务实例精细化调度方法及*** |
CN112052068A (zh) * | 2020-08-17 | 2020-12-08 | 烽火通信科技股份有限公司 | 一种Kubernetes容器平台CPU绑核的方法与装置 |
Non-Patent Citations (1)
Title |
---|
云栖社区V: "助力深度学习!阿里开源可插拔GPU共享调度工具", 《HTTPS://BLOG.CSDN.NET/EO63Y6PKI42ILXR/ARTICLE/DETAILS/88265790》 * |
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN113254186A (zh) * | 2021-06-15 | 2021-08-13 | 阿里云计算有限公司 | 一种进程调度方法、调度器及存储介质 |
CN113742064A (zh) * | 2021-08-06 | 2021-12-03 | 苏州浪潮智能科技有限公司 | 一种服务器集群的资源整理方法、***、设备及介质 |
CN113742064B (zh) * | 2021-08-06 | 2023-08-04 | 苏州浪潮智能科技有限公司 | 一种服务器集群的资源整理方法、***、设备及介质 |
CN113849312A (zh) * | 2021-09-29 | 2021-12-28 | 北京百度网讯科技有限公司 | 数据处理任务的分配方法、装置、电子设备及存储介质 |
CN113687795A (zh) * | 2021-10-25 | 2021-11-23 | 浩鲸云计算科技股份有限公司 | 一种实现有状态应用的存储卷隔离性分配的方法和*** |
CN113821328A (zh) * | 2021-11-23 | 2021-12-21 | 江苏苏宁银行股份有限公司 | 一种容器集群的调度方法、装置、电子设备和存储介质 |
CN115098238A (zh) * | 2022-07-07 | 2022-09-23 | 北京鼎成智造科技有限公司 | 一种应用程序任务调度方法及装置 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN112463349A (zh) | 一种高效调度gpu能力的负载均衡方法及*** | |
CN110647394B (zh) | 一种资源分配方法、装置及设备 | |
CN111966500B (zh) | 资源调度方法、装置、电子设备及存储介质 | |
CN109445944B (zh) | 一种基于dpdk的网络数据采集处理***及其方法 | |
US7620953B1 (en) | System and method for allocating resources of a core space among a plurality of core virtual machines | |
CN111798113B (zh) | 资源分配方法、装置、存储介质和电子设备 | |
CN109522090B (zh) | 资源调度方法及装置 | |
CN116401055B (zh) | 面向资源效率优化的服务器无感知计算工作流编排方法 | |
EP4177751A1 (en) | Resource scheduling method, resource scheduling system, and device | |
CN115858083A (zh) | 容器cpu资源调度与隔离方法和装置、存储介质及电子设备 | |
CN106095581B (zh) | 一种私有云条件下的网络存储虚拟化调度方法 | |
CN114625500A (zh) | 云环境下拓扑感知的微服务应用调度的方法及应用 | |
CN116881009A (zh) | Gpu资源调度方法、装置、电子设备和可读存储介质 | |
Shifrin et al. | Optimal control of VNF deployment and scheduling | |
CN110034963B (zh) | 一种应用集群自适应的弹性配置方法 | |
CN113301087B (zh) | 资源调度方法、装置、计算设备和介质 | |
US20100082528A1 (en) | Method and Apparatus For Optimizing Lead Time For Service Provisioning | |
CN112631766B (zh) | 项目环境资源的动态调整方法及装置 | |
CN115604768B (zh) | 基于资源状态的电磁感知任务动态迁移方法、***及终端 | |
CN111796932A (zh) | 一种gpu资源调度方法 | |
CN115964152A (zh) | Gpu资源调度方法、设备和存储介质 | |
CN116400999A (zh) | 资源调度方法、设备、存储介质和*** | |
CN116010051A (zh) | 一种联邦学习多任务调度方法及装置 | |
CN107294765B (zh) | 一种网络功能虚拟化自适应信任管理方法 | |
Di Stefano et al. | Improving the allocation of communication-intensive applications in clouds using time-related information |
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 | ||
RJ01 | Rejection of invention patent application after publication | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20210309 |