在集群上调度并行作业.pptxVIP

集群上并行作业的调度 21.5基于通信的协同调度 1、基于需求的协同调度 2、隐式协同调度 21.5.1基于需求的协同调度 基于需求的协同调度是在考虑通信模式的情况下决定哪些进程应该被共同调度。这个方法要求通信子系统进行协作，将通信事件通知给调度器。通信子系统能够监视带来消息的目的地，并提高进程的优先级。因而，发送消息进程可能会使得接受进程与它一起被调度。 如果不当的提高接收信息进程的优先级，会带来不公平性问题。用户可能会通过在它们的进程之间发送假消息来提高其程序的优先级。因此，通信子系统只是在不损害公平的基础上才会提高接收消息进程的优先级。 21.5.1基于需求的协同调度 当多个并行作业共同存在于一个系统中时会出现另一个问题。 假设有两个节点，每个节点上都有两个进程，它们分别来自两个并行作业。假定运行于节点1上的作业A的进程A1发送了一个消息给运行于节点2上的作业A的另一个进程A2，于此同时，运行于节点2上的作业B的进程B2发送了一个消息给运行于节点1上的作业B的另一个进程B1。如果系统处理不当就无法解决这个冲突问题，或者可能只是在两个节点上切换进程，而不会协调调度任何一个作业。 21.5.1基于需求的协同调度 一个解决方法是使用纪元数。节点上的纪元数每当上下文被自动切换时就被增加。这个纪元数被加到所有的向外发送的消息屮。当一个节点接收到一个消息时，它将本地的纪元数与到来消息所包含的纪元数进行比较： 如果到来消息包含的纪元数较大,就切换到到来消息所指的目的进程中。在切换的时候,节点同时将到来消息的纪元数作为本机的纪元数。如果到来消息包含的纪元数较小,则拒绝其所要求的进程切换。这样当一个消息到达时它就不会切换回以前的进程。这样就使得新的作业能尽快投入运行，并可在所有的节点上进行协调调度。 21.5.2隐式协同调度 在一个局域网环境中，基于通信的显式调度控制是很难实现的。然而，如果通信是通过UNIX工具(如套接字，socket)来进行的，并且应用程厅是粗粒度的（大量的计算中夹有一些密集的通信），那么这样做也可能是不必要的。原因是在UNIX中进行I/O的进程享有较高的优先级。因此，进程在通信时在它们各自的节点上都具有较高的优先级，并且在通信过程中它们将会得到协同调度。这增大了完全隐式协同调度的可能性， 隐式协同调度中的协同调度行为是不会以任何显式方式出现的。 21.5.2隐式协同调度 当显式调度方法不需要的时候，需要确定的一点就是如果一个通信进程正在等待另一个进程的响应，那么它并不是不可调度的。这是通过使用一个两阶段的阻塞机制来实现的。其主耍思想是等待进程最初将等待一段时间，以期望得到来自另一个进程的响应。但是如果在预定义的时间内没有得到响应，进程将会阻塞并释放处理机以供其他就绪进程使用。易见如果进程等待的时间与进程切换所带来的额外开销相等,就需要有 一个算法来在二者之间进行选择。然而实际情况表明，等待时间应该是五倍于进程切换的 额外开销，这样就为被等待进程在阻塞悄况下提供了足够的唤醒时间。 需要注意的是，隐式协同调度只是当进程正在通信时才要保持进程的执行一致。在计算阶段，进程的执行可能不会保持步调一致。然而这并不重要，因为这时并不交互，不需要进行协同调度。 Dasic算法 21.6 批调度 21.6.1 进入许可控制 21.6.2 实例分析：Utopia/LSF 21.6.1 进入许可控制 HPC应用程序需要高性能，但同时它也给系统带来很重的负载。因此,如果应用程序耗费了过多的系统资源，那么它们将被加以控制。特别是可以在开始的时候就拒绝它们进入系统。 一个通常的办法是使用批调度系统。这类系统定义了一组队列，批处理作业将被提交到这些队列上。每一个队列中都包含着具有某些特定属性，如预计执行时间以及存储需求等的作业。批调度器然后基于作业的属性与可用资源，并根据本地的调度策略来选择作业执行。其他的作业在队列中等待，以便不会使系统过载。 21.6.1 进入许可控制 批调度系统选择哪个工作站来使用也存在着同样的问题。一个解决方法是只使用空闲工作站。然而，这同样存在问题,因为空闲工作站池是在不断变化着的。另一个方法是使用所有的工作站，并优先使用那些负载较轻的。这个方法似乎能起作用，因为工作站所有者的平均交互工作负载虽然有时会有大的瞬间波动，但一般都是相当稳定的。而且，每个工作姑在任 一时刻都只能容纳一个并行作业，以使得交互式工作能够快速抢占系统资源。 21.6.2 实例分析：Utopia/LSF