算法模型平台如何调度资源

Ⅰ linux进程、线程及调度算法（三）

调度策略值得是大家都在ready时，并且CPU已经被调度时，决定谁来运行，谁来被调度。

两者之间有一定矛盾。
响应的优化，意味着高优先级会抢占优先级，会花时间在上下文切换，会影响吞吐。
上下文切换的时间是很短的，几微妙就能搞定。上下文切换本身对吞吐并多大影响， 重要的是，切换后引起的cpu 的 cache miss.
每次切换APP, 数据都要重新load一次。
Linux 会尽可能的在响应与吞吐之间寻找平衡。比如在编译linux的时候，会让你选择 kernal features -> Preemption model.
抢占模型会影响linux的调度算法。

所以 ARM 的架构都是big+LITTLE， 一个很猛CPU+ 多个 性能较差的 CPU, 那么可以把I/O型任务的调度 放在 LITTLE CPU上。需要计算的放在big上。

早期2.6 内核将优先级划分了 0-139 bit的优先级。数值越低，优先级越高。0-99优先级 都是 RT（即时响应）的 ，100-139都是非RT的，即normal。
调度的时候 看哪个bitmap 中的 优先级上有任务ready。可能多个任务哦。

在普通优先级线程调度中，高优先级并不代表对低优先级的绝对优势。会在不同优先级进行轮转。
100 就是比101高，101也会比102高，但100 不会堵着101。
众屌丝进程在轮转时，优先级高的：

初始设置nice值为0，linux 会探测 你是喜欢睡眠，还是干活。越喜欢睡，linux 越奖励你，优先级上升（nice值减少）。越喜欢干活，优先级下降（nice值增加）。所以一个进程在linux中，干着干着 优先级越低，睡着睡着 优先级越高。

后期linux补丁中

红黑树，数据结构， 左边节点小于右边节点
同时兼顾了 CPU/IO 和 nice。
数值代表着 进程运行到目前为止的virtual runtime 时间。

（pyhsical runtime） / weight * 1024(系数)。
优先调度 节点值（vruntime）最小的线程。权重weight 其实有nice 来控制。

一个线程一旦被调度到，则物理运行时间增加，vruntime增加，往左边走。
weight的增加，也导致vruntime减小，往右边走。
总之 CFS让线程 从左滚到右，从右滚到左。即照顾了I/O(喜欢睡，分子小) 也 照顾了 nice值低（分母高）.所以 由喜欢睡，nice值又低的线程，最容易被调度到。
自动调整，无需向nice一样做出奖励惩罚动作，个人理解权重其实相当于nice

但是 此时 来一个 0-99的线程，进行RT调度，都可以瞬间秒杀你！因为人家不是普通的，是RT的!

一个多线程的进程中，每个线程的调度的策略 如 fifo rr normal, 都可以不同。每一个的优先级都可以不一样。
实验举例, 创建2个线程，同时开2个：

运行2次，创建两个进程
sudo renice -n -5(nice -5级别) -g(global)， 会明显看到 一个进程的CPU占用率是另一个的 3倍。

为什么cpu都已经达到200%，为什么系统不觉得卡呢？因为，我们的线程在未设置优先级时，是normal调度模式，且是 CPU消耗型 调度级别其实不高。

利用chrt工具，可以将进程 调整为 50 从normal的调度策略 升为RT （fifo）级别的调度策略，会出现：

chrt , nice renice 的调度策略 都是以线程为单位的，以上 设置的将进程下的所有线程进行设置nice值
线程是调度单位，进程不是，进程是资源封装单位！

两个同样死循环的normal优先级线程，其中一个nice值降低，该线程的CPU 利用率就会比另一个CPU的利用率高。

Ⅱ 操作系统的进程调度算法[总结]

操作系统的进程调度算法直接关系到用户的使用体验。

如果把用户的体验时间，引入到计算机里面，我们引入以下几个概念。

周转时间，指作业从提交系统开始，直到作业完成为止的时间间隔。包括：

是指作业周转时间与作业实际运行服务时间的比值。
平均周转时间和平均带权周转时间是衡量批处理系统调度算法的重要准则。

先来先服务调度算法（First Come First Served, FCFS）是最简单的调度算法，可以用于作业调度和进程调度。
按照作业进入系统后备作业队列的先后次序来挑选作业，加入就绪队列，等待执行。

FCFS是非抢占式的，易于实现，效率不高，性能不好.
有利于长作业（CPU繁忙性）而不利于短作业（I/O繁忙性）。

服务时间：作业需要运行的时间
完成时间 = 开始时间 + 服务时间
等待时间 = 开始时间 - 提交时间
周转时间 = 完成时间 - 提交时间
带权周转时间 = 周转时间 / 服务时间
响应比 = （等待时间 + 服务时间） / 服务时间 = 等待时间/服务时间 + 1

该算法每次从后备作业队列中挑选估计服务时间最短的一个或几个作业，
将他们调入内存，分配必要的资源，创建进程并放入就绪队列。
在进程调度中的原理类似。

SJF是非抢占式的，优先照顾短作业，具有很好的性能，降低平均等待时间，提高吞吐量。
但是不利于长作业，长作业可能一直处于等待状态，出现饥饿现象；
完全未考虑作业的优先紧迫程度，不能用于实时系统。

高响应比优先调度算法（Highest Reponse Ratio First, HRRF）是非抢占式的，主要用于作业调度。
基本思想：每次进行作业调度时，先计算后备作业队列中每个作业的响应比，挑选最高的作业投入系统运行。
响应比 = （等待时间 + 服务时间） / 服务时间 = 等待时间 / 服务时间 + 1

由响应比分析可知，该算法介于FCFS和SJF之间，但是每次需要计算每个作业的响应比，增加系统开销。

Ⅲ 请问任务调度与资源分配的关系是什么！！

亲，网络搜集的数据，希望对你有帮助！云计算是一种商业计算模型。它将计算任务分布在大量计算机构成的资源池上，使各种应用系统能够根据需要获取计算力、存储空间和信息服务。研究背景云计算厂商都有自己资源分配与任务调度模式，但并没有统一的标准和规范。在云计算中，资源分配的效率非常重要，对云计算平台的系统综合性能影响很大。 云计算=(数据软件+平台+基础设施)×服务,从这个公式可以看出资源分配与任务调度成正比，资源分配的越合理，任务调度实行的效率越高！

Ⅳ 怎么优化hadoop任务调度算法

首先介绍了Hadoop平台下作业的分布式运行机制，然后对Hadoop平台自带的4种任务调度器做分析和比较，最后在分析JobTracker类文件的基础上指出了创建自定义任务调度器所需完成的工作。
首先Hadoop集群式基于单服务器的，只有一个服务器节点负责调度整个集群的作业运行，主要的具体工作是切分大数据量的作业，指定哪些Worker节点做Map工作、哪些Worker节点做Rece工作、与Worker节点通信并接受其心跳信号、作为用户的访问入口等等。其次，集群中的每个Worker节点相当于一个器官，运行着主节点所指派的具体作业。这些节点会被分为两种类型，一种是接收分块之后的作业并做映射工作。另一种是负责把前面所做的映射工作按照约定的规则做一个统计。
Task－Tracker通过运行一个简单循环来定期地发送心跳信号（heartbeat）给JobTracker．这个心跳信号会把TaskTracker是否还在存活告知JobTracker，TaskTracker通过信号指明自己是否已经准备
好运行新的任务．一旦TaskTracker已经准备好接受任务，JobTracker就会从作业优先级表中选定一个作业并分配下去．至于到底是执行Map任务还是Rece任务，是由TaskTracker的任务槽所决定的．默认的任务调度器在处理Rece任务之前，会优先填满空闲的Map任务槽．因此，如果TaskTracker满足存在至少一个空闲任务槽时，JobTracker会为它分配Map任务，否则为它选择一个Rece任务．TaskTracker在运行任务的时候，第一步是从共享文件系统中把作业的JAR文件复制过来，从而实现任务文件的本地化．第二步是TaskTracker为任务新建一个本地文件夹并把作业文件解压在此目录中．第三步是由Task－Tracker新建一个TaskRunner实例来运行该任务．
Hadoop平台默认的调度方案就是JobQueueTaskScheler，这是一种按照任务到来的时间先后顺序而执行的调度策略．这种方式比较简单，JobTracker作为主控节点，仅仅是依照作业到来的先后顺序而选择将要执行的作业．当然，这有一定的缺陷，由于Hadoop平台是默认将作业运行在整个集群上的，那么如果一个耗时非常大的作业进入执行期，将会导致其余大量作业长时间得不到运行．这种长时间运行的优先级别并不高的作业带来了严重的作业阻塞，使得整个平台的运行效率处在较低的水平．Hadoop平台对这种FIFO（FirstINAndFirstOut）机制所给出的解决办法是调用SetJobPriority（）方法，通过设置作业的权重级别来做平衡调度．
FairScheler是一种“公平”调度器，它的目标是让每个用户能够公平地共享Hadoop集群计算能力．当只有一个作业运行的时候，它会得到整个集群的资源．随着提交到作业表中作业的增多，Hadoop平台会把集群中空闲出来的时间槽公平分配给每个需要执行的作业．这样即便其中某些作业需要较长时间运行，平台仍然有能力让那些短作业在合理时间内完成［3］．FairScheler支持资源抢占，当一个资源池在一定时段内没有得到公平共享时，它会终止该资源池所获得的过多的资源，同时把这些释放的资源让给那些资源不足的资源池．
Hadoop平台中的CapacityScheler是由Yahoo贡献的，在调度器上，设置了三种粒度的对象：queue，job，task．在该策略下，平台可以有多个作业队列，每个作业队列经提交后，都会获得一定数量的TaskTracker资源．具体调度流程如下．
（1）选择queue，根据资源库的使用情况从小到大排序，直到找到一个合适的job．
（2）选择job，在当前所选定的queue中，按照作业提交的时间先后以及作业的权重优先级别进行排序，选择合适的job．当然，在job选择时还需要考虑所选作业是否超出目前现有的资源上限，以及资源池中的内存是否够该job的task用等因素．
（3）选择task，根据本地节点的资源使用情况来选择合适的task．
虽然Hadoop平台自带了几种调度器，但是上述3种调度方案很难满足公司复杂的应用需求．因此作为平台的个性化使用者，往往需要开发自己的调度器．Hadoop的调度器是在JobTracker中加载和调用的，因此开发一个自定义的调度器就必须搞清楚JobTracker类文件的内部机制．作为Hadoop平台的核心组件，JobTracker监控着整个集群的作业运行情况并对资源进行管理调度．每个Task－Tracker每隔3s通过heartbeat向JobTracker汇报自己管理的机器的一些基本信息，包括内存使用量、内存的剩余量以及空闲的slot数目等等［5］．一
旦JobTracker发现了空闲slot，便会调用调度器中的AssignTask方法为该TaskTracker分配task。

Ⅳ cpu调度的基本方式

我们知道，程序需要获得CPU的资源才能被调度和执行，那么当一个进程由于某种原因放弃CPU然后进入阻塞状态，下一个获得CPU资源去被调度执行的进程会是谁呢？下图中，进程1因为阻塞放弃CPU资源，此时，进程2刚IO操作结束，可以获得CPU资源去被调度，进程3的时间片轮转结束，也同样可以获得CPU资源去被调度，那么，此时的操作系统应该安排哪个进程去获得CPU资源呢？这就涉及到我们操作系统的CPU调度策略了。

根据生活中的例子，我们很容易想到以下两种策略CPU调度的直观想法：1.FIFO谁先进入，先调度谁，这是一种非常简单有效的方法，就好比我们去饭堂打饭，谁先到就给谁先打饭。但是这种策略会遇到一个问题：如果遇到一个很小的任务，但是它是最后进入的，那么必须得前面一大堆任务结束完后才能执行这个小小的任务，这样就感觉很不划算呀！因为我只是简简单单的一个小任务，但是从打开这个任务到结束这个任务要很久。这显然不符合我们的需求，因而我们会想到第2种策略，就是先调度小任务，后调度大任务。2.Priority很简单，就是任务短的优先执行，但是此时又有问题了，任务虽然短，但是它的执行时间不一定短，就好比在一个银行业务中，客户填写一个表，这是一个非常短的任务吧——就单单填个表，但是这个表很长很长，那么这个短任务它的执行时间就很长了，我们怎么知道这个短的任务将来会执行多长的时间呢？所以，这样的策略还是依然有问题。那么，面对诸多的场景，如何设计调度算法呢？首先，我们要明白我们的算法应该让什么更好呢？面对客户：银行调度算法的设计目标应该是用户满意；而面对进程：CPU调度的目标应该是进程满意。那怎么才能让进程满意呢？那就是时间了。进程希望尽早地结束任务，这就是周转时间(从任务到达到任务结束)要短，而且希望用户的操作能够尽快地被响应，这就是响应时间(从操作发生到响应)要短。而且系统内耗时间要少，吞吐量(任务的完成量)要大，系统需要把更多的时间用在任务的执行上，而不能老是去做无关紧要的事情，例如：频繁切换任务，切换栈，分配资源等事情。同时，系统还要去合理地调配任务。那么，CPU的调度策略如何做到合理呢？首先得明白系统中有以下的几种矛盾。1.吞吐量和响应时间之间有矛盾响应时间小=>切换次数多=>系统内耗大=>吞吐量小由于需要较短的响应时间，那么就得频繁地切换任务，这样系统的很多时间都花在切换任务上面了，系统的内耗大了，吞吐量就小了。2.前台任务和后台任务的关注点不同前台任务关注响应时间，后台任务关注周转时间。前台任务例如我们的word文档，我们打一个字，需要立马显示在文档中，这就是word文档这个任务关注的是响应时间；而后台任务中，例如我们的javac编译java代码，它的周转时间要小，即该任务从进入到结束所花的时间要小，即编译完成的时间要小。http://3.IO约束型任务和CPU约束型任务各有各的特点IO约束型任务就是使用CPU的时间较少，进行IO操作的时间较长，CPU约束型的任务就是使用CPU的时间较长。因此，要做到合理，需要折中、综合考虑以上的几种矛盾。由此，产生了一些CPU的调度算法，在下一节我们将重点讲述这些CPU调度算法。

关注小鲸融创，一起深度学习金融科技！

编辑于 2019-12-11 · 着作权归作者所有
赞同 1
评论
展开全部

Ⅵ 做数据集群训练，如何比较好的资源调度做到程序稳定（多深度学习GPU的调度策略）

蓝海大脑液冷数据中心研发人员指出：这是一个就是GPU集群管理调度的一个问题，现在主流的GPU系统在国内可以分成2部分，一类是交通系统，一类是基于容器的一个比如K8S的调度编排的一个调度系统。K8S里面是支持了GPU设备的自发现，然后你只是去提交GPU的一个请求的个数以及GPU资源的类型，然后它会自动去帮你去做调度。另外的话是以HPC为传统的那种，比如说PPS或SLAM调度，SLAM里面也有支持GPU设备的一个自我调度，然后把GPU设备作为一个计算对象可以去请求。当然由于GPU系统的拓扑结构是一样的，不同的调度算法，给你分配的GPU资源可能会存在一些GPU拓扑不是最优的情况。然后针对这种情况，不管是SLAM还是K8S系统，NVIDIA写了一个拓扑自我检测的小程序算法，它可以很好的集成到K8S以及SLAM里面，然后在做GPU资源分配时，根据这个算法去分配GPU资源，以保证你分配的CPU资源是最优的，拓扑最优，而且也会保证以后的分配，对以后资源的拓扑最优也会有保证。

Ⅶ 设计一套调度算法,算法既支持批处理任务,又支持普通的分时进程,还支持实时任务，说明设计思路。

考多级反馈队列 ，能满足题设的要求 汤子赢 教材上 有介绍

调度算法
在操作系统中调度是指一种自远方分配，因而调度算法是指：根据系统的资源分配策略所规定的资源分配算法。对于不同的的系统和系统目标，通常采用不同的调度算法，例如，在批处理系统中，为了照顾为数众多的段作业，应采用短作业优先的调度算法；又如在分时系统中，为了保证系统具有合理的响应时间，应当采用轮转法进行调度。目前存在的多种调度算法中，有的算法适用于作业调度，有的算法适用于进程调度；但也有些调度算法既可以用于作业调度，也可以用于进程调度。

Ⅷ 如何将蚁群算法植入cloudsim作为资源调度策略

cloudsim是澳大利亚墨尔本大学的网格实验室和Gridbus项目宣布推出的云计算仿真软件。
主要类的介绍：

Cloudlet类：构建云环境下的任务。
DataCenter类：数据中心，支持虚拟化的网格资源，处理虚拟机上面的信息查询，也包含虚拟机对资源的分配策略的处理。
DataCenterBroker类：隐藏了虚拟机的管理，如创建、任务提交、虚拟机的销毁等，即是一个代理业务。
Host类：扩展了机器对虚拟机除处理单元(PE)之外的参数分配策略，如带宽、存储空间、内存等，一台Host可对应多台虚拟机。
VirtualMachine类：虚拟机类，运行在Host上，与其它虚拟机共享资源，每台虚拟机由一个拥有者所有，可提交任务，并由VMScheler类定制该虚拟机的调度策略。
VMScheler类：虚拟机的调度策略，用来管理执行任务，实现了任务接口。
VMCharacteristics类：提供虚拟机描述。
VMMAllocationPolicy类：虚拟机监视器策略类，描述同一Host上的多台虚拟机共享资源的策略。

VMProvisioner类：实现数据中心的主机到虚拟机的映射。
主要过程：
①初始化一些值。
②创建数据中心,本实验中为两个数据中心：
DataCenter Mydatacenter_0 = createDatacenter(“MyDatacenter_0”);
DataCenter Mydatacenter_1 = createDatacenter(“MyDatacenter_1”);

③创建数据中心的代理业务：
DatacenterBroker broker = createBroker();
Int brokerId = broker.get_id();//获取代理的ID:
④创建虚拟机列表:

Private static VirtualMachineList cerateVm(int userID,int vms)
{
VirtualMachineList list = new VirtualMachineList();

//VM 一些基本参数
Long size = 10000;

Int vcpus = 1;

Int priority = 1;
String vmm = “bingchean”;//my name
//创建一个虚拟机列表数组
VirtualMachineList[] Myvm = new VirtualMachineList[vms];
For(int i = 0;i < vms;i++)
{
Vm[i] = new VirtualMachine
(new VMCharacteristics(i,usersID,size,memory,bw,vcpus,priority,
vmm,new TimeSharedVMScheler()));
//将每个创建好的虚拟机放入列表
List.add(vm[i]);
}
Return list;}

//创建15个虚拟机.
vmlist = createVM(brokerID,15);

//创建40个任务
cloudletlist = createCloudletlist(brokerId,40);

⑤提交任务列表和虚拟机列表
Broker.submitVMList(vmlist);
Broker.submitCloudletList(cloudletlist);

⑥开始仿真.
GridSim.startGridSimulation();
CloudletList newList = broker.getCloudletList();

⑦仿真结束,停止实验,打印结果.
GridSim.stop GridSimulation();
printCloudletList(newList);

⑧打印每个数据中心的dept值.
Mydatacenter_0.printDepts();
Mydatacenter_1.printDepts();

实验里运用蚁群算法对资源分配，和普通的没使用蚁群算法的随机算法进行资源分配的实验进行了对比。创建了两个数据中心，15个虚拟机，分别执行20,30,40,50,60个任务,上图中选取的是执行40个任务时的状态.最后是通过QoS标准对交付给用户的服务进行评判.
结果：

。。。。。太长

执行20个资源:平均耗时:
(4*40 + 11*80 + 3*60 + 2*160) / 15 = 102.67

执行30个资源:平均耗时:
(16*80 + 6*120 + 8*160) / 15 = 218.67

执行40个资源:平均耗时:
(4*80+24*120+12*240) / 15 = 405.33

执行50个资源:平均耗时:
(12*120 + 16*160 + 9*180 + 9*240 + 4*320) / 15 = 601.33

执行60个资源:平均耗时
(32*160 + 12*240 + 16*320) / 15 = 874.67
----------------------------------------------------------------------------------------------------------------

Qos中约束条件可以表述为:

要最终寻找的路径要保证最短,且保证T(R)要最小,在图G中寻找的范围约束条件为满足上式中的ABC.这样做就可以保证云计算在资源分配策略上满足QoS标准.

Ⅸ 确定作业调度算法的原则是什么

①先来先服务算法。原则上按照作业进入输入井的次序调度，如果作业的资源得不到满足，将会推迟调度，它的资源得到满足的时候会优先被调度进来。

优点：具有一定的公平性。

缺点：系统的吞吐率低，平均周转时间长，有大作业到来的时，许多小作业推迟调度。

②计算时间短的作业优先．优先调度计算时间短的作业进行调度，资源不满足的情况下推迟调度。在这种调度算法下，要求用户要对作业的计算时间预先有一个估计，调度以此为依据。

优点：由于被选中的作业计算时间，所以不能尽快地完成并退出系统，降低了作业的平均等待时间，提高了系统的吞吐率。

缺点：大作业会不满意，而且极限情况下使得某些大作业始终得不到调度。

③响应比高者优先算法。该算法考虑了计算时间等待时间，既考虑了计算时间短的作业优先，又考虑了大作业长期等待的问题。所谓响应比是按照以下公式来定义的：

响应比R=等待时间/计算时间

这里的计算时间是估计的作业计算时间，从公式看，计算时间越短，响应比越高；而另一方面，大作业等待时间越长，响应比也会越大。一个作业完成以后，需要重新计算一下在输入井中的各个作业的响应比，最高的将优先调度。

④优先数调度算法。为每一个作业指定一个优先数，优先数高的作业先被调度。对于优先数相等的作业采用先来先服务的策略。优先数的制定原则是：作业的缓急程序，估计的计算时间，作业的等待时间，资源申请情况等因素综合考虑。

⑤均衡调度算法。使用不同资源的进程同时执行，减少作业等待同类设备而耗费的时间，加快作业的执行。

(9)算法模型平台如何调度资源扩展阅读：

在操作系统中调度是指一种资源分配，因而调度算法是指：根据系统的资源分配策略所规定的资源分配算法。对于不同的的系统和系统目标，通常采用不同的调度算法，例如，在批处理系统中，为了照顾为数众多的段作业，应采用短作业优先的调度算法；又如在分时系统中，为了保证系统具有合理的响应时间，应当采用轮转法进行调度。

目前存在的多种调度算法中，有的算法适用于作业调度，有的算法适用于进程调度；但也有些调度算法既可以用于作业调度，也可以用于进程调度。

Ⅹ Mesos 资源分配&调度

mesos采用双层调度方案, master决定将多少资源分配给framework, 如何使用由framework决定, 流程：

Mesos通过支配资源公平算法(DRF)进行资源分配
概念：
最大-最小资源公平算法：
支配资源：在总资源比例最大的资源类型
支配比例：支配资源所在总资源的比例
例如：总资源为<8 CPU, 32 G>，框架A申请<2CPU, 1G>， 则支配资源为max([2/8, 1/32])，即cpu为支配资源，其支配比例为25%
DRF算法是在每个框架的支配资源上在利用最大-最小资源公平算法进行资源分配

Mesos FrameworkInfo中的用户角色可以用来决定资源的分配，可以每个用户或者每个框架一个角色，或者多个用户和框架共享一个角色，若未显示设置，则为运行框架调度器的用户

加权DRF：
在Mesos master启动时可以通过--weights和--roles设置加权DRF, --weights后接角色/权重列表格式为role1=weight1,权重为非整数，且roles中设置的角色必须都在weights设置权重

静态预留：
在slave上可以通过resource参数设置某部分资源只能由某角色使用，格式为name(role)value的列表，若没有指定角色的资源和未出现的资源将被划分到默认角色下, 例如
--resources="cpus:4;mem:2048;cpus(proct):8;mem(proct):4096"
指将8个cpu，4096M内存的slave预留给proct角色
修改resources属性后需要重启slave

动态预留:
在framework接受到offer可以发送Offer::Operations::Reserve和Offer::Operations::Unreserve管理预留资源
也可以通过/reserve和/unreserve两个restapi对资源预留进行管理，此时不需要重启slave