精华内容
下载资源
问答
  • 本文作者通过阿里巴巴容器平台团队在这一领域的工作实践,整理出了一套资源利用提升的方案,希望能够带给大家带来一些讨论和思考。 引言 不知道大家有没有过这样的经历:当我们拥有了一套 Kubernetes 集群,然...

    作者 | 张晓宇(衷源) 阿里云容器平台技术专家

    关注『阿里巴巴云原生』公众号,回复关键词“1010”,可获取本文 PPT。

    **导读:**资源利用率一直是很多平台管理和研发人员关心的话题。本文作者通过阿里巴巴容器平台团队在这一领域的工作实践,整理出了一套资源利用提升的方案,希望能够带给大家带来一些讨论和思考。

    引言

    不知道大家有没有过这样的经历:当我们拥有了一套 Kubernetes 集群,然后开始部署应用的时候,我们应该给容器分配多少资源呢?

    这很难说。由于 Kubernetes 自己的机制,我们可以理解容器的资源实质上是一个静态的配置。

    • 如果我发现资源不足,为了分配给容器更多资源,我们需要重建 Pod;
    • 如果分配冗余的资源,那么我们的 worker node 节点似乎又部署不了多少容器。

    试问,我们能做到容器资源的按需分配吗?接下来,我们将在本次分享中和大家一起进行探讨这个问题的答案。

    生产环境中的真实挑战

    首先请允许我们根据我们的实际情况抛出我们实际生产环境的挑战。或许大家还记得 2018 年的天猫双 11,这一天的总成交额达到了 2135 亿。由此一斑可窥全豹,能够支撑如此庞大规模的交易量背后的系统,其应用种类和数量应该是怎样的一种规模。

    在这种规模下,我们常常听到的容器调度,如:容器编排,负载均衡,集群扩缩容,集群升级,应用发布,应用灰度等等这些词,在被“超大规模集群”这个词修饰后,都不再是件容易处理的事情。规模本身也就是我们最大的挑战。如何运营和管理好这么一个庞大的系统,并遵循业界 dev-ops 宣传的那样效果,犹如让大象去跳舞。但是马老师曾说过,大象就该干大象该干的事情,为什么要去跳舞呢。

    Kubernetes 的帮助

    k1

    大象是否可以跳舞,带着这个问题,我们需要从淘宝、天猫等 APP 背后系统说起。

    这套互联网系统应用部署大致可分为三个阶段,传统部署,虚拟机部署和容器部署。相比于传统部署,虚拟机部署有了更好的隔离性和安全性,但是在性能上不可避免的产生了大量损耗。而容器部署又在虚拟机部署实现隔离和安全的背景下,提出了更轻量化的解决方案。我们的系统也是沿着这么一条主航道上运行的。假设底层系统好比一艘巨轮,面对巨量的集装箱—容器,我们需要一个优秀的船长,对它们进行调度编排,让系统这艘大船可以避开层层险阻,操作难度降低,且具备更多灵活性,最终达成航行的目的。

    理想与现实

    在开始之初,想到容器化和 Kubernetes 的各种美好场景,我们理想中的容器编排效果应该是这样的:

    • 从容:我们的工程师更加从容的面对复杂的挑战,不再眉头紧锁而是更多笑容和自信;
    • 优雅:每一次线上变更操作都可以像品着红酒一样气定神闲,优雅地按下执行的回车键;
    • 有序:从开发到测试,再到灰度发布,一气呵成,行云流水;
    • 稳定:系统健壮性良好,任尔东西南北风,我们系统岿然不动。全年系统可用性 N 多个 9;
    • 高效:节约出更多人力,实现“快乐工作,认真生活”。

    然而理想很丰满,现实很骨感。迎接我们的却是杂乱和形态各异的窘迫。

    杂乱,是因为作为一个异军突起的新型技术栈,很多配套工具和工作流的建设处于初级阶段。Demo 版本中运行良好的工具,在真实场景下大规模铺开,各种隐藏的问题就会暴露无遗,层出不穷。从开发到运维,所有的工作人员都在各种被动地疲于奔命。另外,“大规模铺开”还意味着,要直接面对形态各异的生产环境:异构配置的机器、复杂的需求,甚至是适配用户的既往的使用习惯等等。

    k2

    除了让人心力交瘁的混乱,系统还面临着应用容器的各种崩溃问题:内存不足导致的 OOM,CPU quota 分配太少,导致进程被 throttle,还有带宽不足,响应时延大幅上升…甚至是交易量在面对访问高峰时候由于系统不给力导致的断崖式下跌等等。这些都使我们在大规模商用 Kubernetes 场景中积累非常多的经验。

    直面问题

    稳定性

    问题总要进行面对的。正如某位高人说过:如果感觉哪里不太对,那么肯定有些地方出问题了。于是我们就要剖析,问题究竟出在哪里。针对于内存的 OOM,CPU 资源被 throttle,我们可以推断我们给与容器分配的初始资源不足。

    k3

    资源不足就势必造成整个应用服务稳定性下降。例如上图的场景:虽然是同一种应用的副本,或许是由于负载均衡不够强大,或者是由于应用自身的原因,甚至是由于机器本身是异构的,相同数值的资源,可能对于同一种应用的不同副本并具有相等的价值和意义。在数值上他们看似分配了相同的资源,然而在实际负载工作时,极有可能出现的现象是肥瘦不均的。

    k4

    而在资源 overcommit 的场景下,应用在整个节点资源不足,或是在所在的 CPU share pool 资源不足时,也会出现严重的资源竞争关系。资源竞争是对应用稳定性最大的威胁之一。所以我们要尽力在生产环境中清除所有的威胁。

    我们都知道稳定性是件很重要的事情,尤其对于掌控上百万容器生杀大权的一线研发人员。或许不经心的一个操作就有可能造成影响面巨大的生产事故。

    因此,我们也按照一般流程做了系统预防和兜底工作。

    • 在预防维度,我们可以进行全链路的压力测试,并且提前通过科学的手段预判应用需要的副本数和资源量。如果没法准确预算资源,那就只采用冗余分配资源的方式了。
    • 在兜底维度,我们可以在大规模访问流量抵达后,对不紧要的业务做服务降级并同时对主要应用进行临时扩容。

    但是对于陡然增加几分钟的突增流量,这么多组合拳的花费不菲,似乎有些不划算。或许我们可以提出一些解决方案,达到我们的预期。

    资源利用率

    回顾一下我们的应用部署情况:节点上的容器一般分属多种应用,这些应用本身不一定,也一般不会同时处于访问的高峰。对于混合部署应用的宿主机,如果能都错峰分配上面运行容器的资源或许更科学。

    k5

    应用的资源需求可能就像月亮一样有阴晴圆缺,有周期变化。例如在线业务,尤其是交易业务,它们在资源使用上呈现一定的周期性,例如:在凌晨、上午时,它的使用量并不是很高,而在午间、下午时会比较高。

    打个比方:对于 A 应用的重要时刻,对于 B 应用可能不那么重要,适当打压 B 应用,腾挪出资源给 A 应用,这是个不错的选择。这听起来有点像是分时复用的感觉。但是如果我们按照流量峰值时的需求配置资源就会产生大量的浪费。

    k6

    除了对于实时性要求很高的在线应用外,我们还有离线应用和实时计算应用等:离线计算对于 CPU 、Memory 或网络资源的使用以及时间不那么敏感,所以在任何时间段它都可以运行;实时计算,可能对于时间敏感性就会很高。

    早期,我们业务是在不同的节点按照应用的类型独立进行部署。从上面这张图来看,如果它们进行分时复用资源,针对实时性这个需求层面,我们会发现它实际的最大使用量不是 2 2 1=5,而是某一时刻重要紧急应用需求量的最大值,也就是 3 。如果我们能够数据监测到每个应用的真实使用量,给它分配合理值,那么就能产生资源利用率提升的实际效果。

    对于电商应用,对于采用了重量级 Java 框架和相关技术栈的 Web 应用,短时间内 HPA 或者 VPA 都不是件容易的事情。

    先说 HPA,我们或许可以秒级拉起了 Pod,创建新的容器,然而拉起的容器是否真的可用呢。从创建到可用,可能需要比较久的时间,对于大促和抢购秒杀-这种访问量“洪峰”可能仅维持几分钟或者十几分钟的实际场景,如果我们等到 HPA 的副本全部可用,可能市场活动早已经结束了。

    至于社区目前的 VPA 场景,删掉旧 Pod,创建新 Pod,这样的逻辑更难接受。所以综合考虑,我们需要一个更实际的解决方案弥补 HPA 和 VPA 的在这一单机资源调度的空缺。

    解决方案

    交付标准

    我们首先要对解决方案设定一个可以交付的标准那就是—— “既要稳定性,也要利用率,还要自动化实施,当然如果能够智能化那就更好”,然后再交付标准进行细化:

    • 安全稳定:工具本身高可用。所用的算法和实施手段必须做到可控;
    • 业务容器按需分配资源:可以及时根据业务实时资源消耗对不太久远的将来进行资源消耗预测,让用户明白业务接下来对于资源的真实需求;
    • 工具本身资源开销小:工具本身资源的消耗要尽可能小,不要成为运维的负担;
    • 操作方便,扩展性强:能做到无需接受培训即可玩转这个工具,当然工具还要具有良好扩展性,供用户 DIY;
    • 快速发现 & 及时响应:实时性,也就是最重要的特质,这也是和HPA或者VPA在解决资源调度问题方式不同的地方。

    设计与实现

    k7

    上图是我们最初的工具流程设计:当一个应用面临很高的业务访问需求时,体现在 CPU、Memory 或其他资源类型需求量变大,我们根据 Data Collector 采集的实时基础数据,利用 Data Aggregator 生成某个容器或整个应用的画像,再将画像反馈给 Policy engine。 Policy engine 会瞬时快速修改容器 Cgroup 文件目录下的的参数。

    我们最早的架构和我们的想法一样朴实,在 kubelet 进行了侵入式的修改。虽然我们只是加了几个接口,但是这种方式确实不够优雅。每次 kubenrnetes 升级,对于 Policy engine 相关组件升级也有一定的挑战。

    k8

    为了做到快速迭代并和 Kubelet 解耦,我们对于实现方式进行了新的演进。那就是将关键应用容器化。这样可以达到以下功效:

    • 不侵入修改 K8s 核心组件;
    • 方便迭代&发布;
    • 借助于 Kubernetes 相关的 QoS Class 机制,容器的资源配置,资源开销可控。

    当然在后续演进中,我们也在尝试和 HPA,VPA 进行打通,毕竟这些和 Policy engine 存在着互补的关系。因此我们架构进一步演进成如下情形。当 Policy engine 在处理一些更多复杂场景搞到无力时,上报事件让中心端做出更全局的决策。水平扩容或是垂直增加资源。

    k9

    下面我们具体讨论一下 Policy engine 的设计。Policy engine 是单机节点上进行智能调度并执行 Pod 资源调整的核心组件。它主要包括 api server,指挥中心 command center 和执行层 executor。

    • 其中 api server 用于服务外界对于 policy engine 运行状态的查询和设置的请求;
    • command center 根据实时的容器画像和物理机本身的负载以及资源使用情况,作出 Pod 资源调整的决策;
    • Executor 再根据 command center 的决策,对容器的资源限制进行调整。同时,executor 也把每次调整的 revision info 持久化,以便发生故障时可以回滚。

    指挥中心定期从 data aggregator 获取容器的实时画像,包括聚合的统计数据和预测数据,首先判断节点状态,例如节点磁盘异常,或者网络不通,表示该节点已经发生异常,需要保护现场,不再对Pod进行资源调整,以免造成系统震荡,影响运维和调试。如果节点状态正常,指挥中心会策略规则,对容器数据进行再次过滤。比如容器 CPU 率飙高,或者容器的响应时间超过安全阈值。如果条件满足,则对满足条件的容器集合给出资源调整建议,传递给executor。

    在架构设计上,我们遵循了以下原则:

    • 插件化:所有的规则和策略被设计为可以通过配置文件来修改,尽量与核心控制流程的代码解耦,与 data collector 和 data aggregator 等其他组件的更新和发布解耦,提升可扩展性;

    • 稳定,这包括以下几个方面:

      • 控制器稳定性。指挥中心的决策以不影响单机乃至全局稳定性为前提,包括容器的性能稳定和资源分配稳定。例如,目前每个控制器仅负责一种 cgroup 资源的控制,即在同一时间窗口内,Policy engine 不同时调整多种资源,以免造成资源分配震荡,干扰调整效果;
      • 触发规则稳定性。例如,某一条规则的原始触发条件为容器的性能指标超出安全阈值,但是为避免控制动作被某一突发峰值触发而导致震荡,我们把触发规则定制为:过去一段时间窗口内性能指标的低百分位超出安全阈值;如果规则满足,说明这段时间内绝大部分的性能指标值都已经超出了安全阈值,就需要触发控制动作了;
      • 另外,与社区版 Vertical-Pod-Autoscaler 不同,Policy engine 不主动驱逐腾挪容器,而是直接修改容器的 cgroup 文件;
    • 自愈:资源调整等动作的执行可能会产生一些异常,我们在每个控制器内都加入了自愈回滚机制,保证整个系统的稳定性;

    • 不依赖应用先验知识:为所有不同的应用分别进行压测、定制策略,或者提前对可能排部在一起的应用进行压测,会导致巨大开销,可扩展性降低。我们的策略在设计上尽可能通用,尽量采用不依赖于具体平台、操作系统、应用的指标和控制策略。

    在资源调整方面,Cgroup 支持我们对各个容器的 CPU、内存、网络和磁盘 IO 带宽资源进行隔离和限制,目前我们主要对容器的 CPU 资源进行调整,同时在测试中探索在时分复用的场景下动态调整 memory limit 和 swap usage 而避免 OOM 的可行性;在未来我们将支持对容器的网络和磁盘 IO 的动态调整。

    调整效果

    k10

    上图展示了我们在测试集群得到的一些实验结果。我们把高优先级的在线应用和低优先级的离线应用混合部署在测试集群里。SLO 是 250ms,我们希望在线应用的 latency 的 95 百分位值低于阈值 250ms。

    在实验结果中可以看到:

    • 在大约90s前,在线应用的负载很低;latency 的均值和百分位都在 250ms 以下;
    • 到了 90s后,我们给在线应用加压,流量增加,负载也升高,导致在线应用 latency 的 95 百分位值超过了 SLO;
    • 在大约 150s 左右,我们的小步快跑控制策略被触发,渐进式地 throttle 与在线应用发生资源竞争的离线应用;
    • 到了大约 200s 左右,在线应用的性能恢复正常,latency 的 95 百分位回落到 SLO 以下。

    这说明了我们的控制策略的有效性。

    经验和教训

    下面我们总结一下在整个项目的进行过程中,我们收获的一些经验和教训,希望这些经验教训能够对遇到类似问题和场景的人有所帮助。

    1. 避开硬编码,组件微服务化,不仅便于快速演进和迭代,还有利于熔断异常服务。
    2. 尽可能不要调用类库中还是 alpha 或者 beta 特性的接口。 例如我们曾经直接调用 CRI 接口读取容器的一些信息,或者做一些更新操作,但是随着接口字段或者方法的修改,共建有些功能就会变得不可用,或许有时候,调用不稳定的接口还不如直接获取某个应用的打印信息可能更靠谱。
    3. 基于 QoS 的资源动态调整方面:如我们之前所讲,阿里集团内部有上万个应用,应用之间的调用链相当复杂。应用 A 的容器性能发生异常,不一定都是在单机节点上的资源不足或者资源竞争导致,而很有可能是它下游的应用 B、应用 C,或者数据库、cache 的访问延迟导致的。由于单机节点上这种信息的局限性,基于单机节点信息的资源调整,只能采用“尽力而为”,也就是 best effort 的策略了。在未来,我们计划打通单机节点和中心端的资源调控链路,由中心端综合单机节点上报的性能信息和资源调整请求,统一进行资源的重新分配,或者容器的重新编排,或者触发 HPA,从而形成一个集群级别的闭环的智能资源调控链路,这将会大大提高整个集群维度的稳定性和综合资源利用率。
    4. 资源v.s.性能模型:可能有人已经注意到,我们的调整策略里,并没有明显地提出为容器建立“资源v.s.性能”的模型。这种模型在学术论文里非常常见,一般是对被测的几种应用进行了离线压测或者在线压测,改变应用的资源分配,测量应用的性能指标,得到性能随资源变化的曲线,最终用在实时的资源调控算法中。在应用数量比较少,调用链比较简单,集群里的物理机硬件配置也比较少的情况下,这种基于压测的方法可以穷举到所有可能的情况,找到最优或者次优的资源调整方案,从而得到比较好的性能。但是在阿里集团的场景下,我们有上万个应用,很多重点应用的版本发布也非常频繁,往往新版本发布后,旧的压测数据,或者说资源性能模型,就不适用了。另外,我们的集群很多是异构集群,在某一种物理机上测试得到的性能数据,在另一台不同型号的物理机上就不会复现。这些都对我们直接应用学术论文里的资源调控算法带来了障碍。所以,针对阿里集团内部的场景,我们采用了这样的策略:不对应用进行离线压测,获取显示的资源性能模型。而是建立实时的动态容器画像,用过去一段时间窗口内容器资源使用情况的统计数据作为对未来一小段时间内的预测,并且动态更新;最后基于这个动态的容器画像,执行小步快跑的资源调整策略,边走边看,尽力而为。

    总结与展望

    总结起来,我们的工作主要实现了以下几方面的收益:

    • 通过分时复用以及将不同优先级的容器(也就是在线和离线任务)混合部署,并且通过对容器资源限制的动态调整,保证了在线应用在不同负载情况下都能得到足够的资源,从而提高集群的综合资源利用率。
    • 通过对单机节点上的容器资源的智能动态调整,降低了应用之间的性能干扰,保障高优先级应用的性能稳定性
    • 各种资源调整策略通过 Daemonset 部署,可以自动地、智能地在节点上运行,减少人工干预,降低了运维的人力成本。

    展望未来,我们希望在以下几个方面加强和扩展我们的工作:

    • 闭环控制链路:前面已经提到,单机节点上由于缺乏全局信息,对于资源的调整有其局限性,只能尽力而为。未来,我们希望能够打通与 HPA 和 VPA 的通路,使单机节点和中心端联动进行资源调整,最大化弹性伸缩的收益。
    • 容器重新编排:即使是同一个应用,不同容器的负载和所处的物理环境也是动态变化的,单机上调整 pod 的资源,不一定能够满足动态的需求。我们希望单机上实时容器画像,能够为中心端提供更多的有效信息,帮助中心端的调度器作出更加智能的容器重编排决策。
    • 策略智能化:我们现在的资源调整策略仍然比较粗粒度,可以调整的资源也比较有限;后续我们希望让资源调整策略更加智能化,并且考虑到更多的资源,比如对磁盘和网络IO带宽的调整,提高资源调整的有效性。
    • 容器画像精细化:目前的容器画像也比较粗糙,仅仅依靠统计数据和线性预测;刻画容器性能的指标种类也比较局限。我们希望找到更加精确的、通用的、反映容器性能的指标,以便更加精细地刻画容器当前的状态和对不同资源的需求程度。
    • 查找干扰源:我们希望能找到在单机节点上找到行之有效的方案,来精准定位应用性能受损时的干扰源;这对策略智能化也有很大意义。

    Q & A

    **Q1:**直接修改 cgroup 容器一定会获得资源吗?
    **A1:**容器技术隔离的技术基础就是 cgroup 层面。在宿主机腾出足够资源的情况下,给 cgroup 设置更大的值可以获取更多的资源。同理,对于一般优先级不高的应用,设置较低的 cgroup 资源值就会达到抑制容器运行的效果。

    **Q2:**底层是如何区分在线和离线优先级的?
    **A2:**底层是无法自动获取谁是在线,谁是离线,或者谁的优先级高,谁的优先级低的。这个我们可以通过各种 Kubernetes 提供的扩展实现。最简单的是通过 label,Annotation 标识。当然通过扩展 QoS class 也是一种思路。社区版本的 QoS class设置太过于保守,给予用户发挥的空间不大。我们通过这些方面也进行了增强。在合适的时候或许会推向社区。自动感知是个方向,感知谁是干扰源,感知谁是某种资源型应用,这块我们还在研发中。做到真正的动态,肯定是具备自动感知的智能系统。

    Q3:“与社区版 Vertical-Pod-Autoscaler 不同,Policy engine 不主动驱逐腾挪容器,而是直接修改容器的 cgroup 文件”,想问一下,不主动驱逐的话,如果 Node 的资源达到上线了会怎么处理?
    **A3:**这是一个好问题。首先这里要先区分是哪种资源,如果是 CPU 型的,我们可以调整低优先级容器的 cgroup 下 cpu quota 的值,首先抑制低优先级的容器对于 CPU 的争抢。然后再适当上调高优先级容器的相关资源值。如果是内存型资源,这个不能直接去缩小低优先级容器的 cgroup 值,否则会造成 OOM,对于学习内存型资源的调整,我们会在其他分享中继续讨论。这个技术比较特殊。

    **Q4:**只修改 cgroup,怎么保证 K8s 对单个物理机能够分配更多的容器?
    **A4:**文字直播有了一定说明,容器的资源消耗并非是一成不变的,很多时候它们的资源消耗呈现潮汐现象,相同的资源条件下部署更多应用,完成更多作业就是达到资源利用的最大化的效果。资源出现超卖才是我们这个主题讨论的最大价值。

    **Q5:**也就是说,低优先级的容器,request 设置的比 limit 小很多,然后你们再动态的调整 cgroup?
    **A5:**在现有 QoS 场景下,你可以理解被调整的 Pod 都是 burstable 的。但是我们并不是直接调整 Pod 元数据的 limit 的值,而是调整 limit 在 cgroup 反映的值,这个值在资源竞争缓和的时候还会被调整回去的。我们并不建议单机的 cgroup 数据和 etcd 的中心数据割裂太久。如果长期偏离,我们会像 VPA 发出警报,联动 VPA 做调整。当然在容器运行的高峰期,任何重建容器的操作都是不明智的。

    **Q6:**整体的理解就是你们开始就让物理机超配了一定比例的 pod,然后通过策略动态调整容器的 cgroup 值?
    **A6:**如果资源完全是富足冗余的,这个动态调整也有一定意义。就是并非资源用满场景下,高优先级应用会被干扰,实际上,当主机的 CPU 达到一定比例,打个比方例如 50%,应用的时延就变大。为了完全确保高优先级应用的 SLO,牺牲低优先级的 CPU 正常运行也是有价值的。

    **Q7:**Policy engine 有没有考虑开源?
    **A7:**有计划进行开源,Policy engine 更多的是和自身的应用属性相关,电商应用或者大数据处理应用的策略都是不相同的,我们开源会首先开源框架和附带一些简单的策略,更多的策略可以用户自定义。

    **Q8:**我之前遇到的大部分应用都无法正确感知 cgroup 的配置,因此很多情况都需要在启动参数里面根据 cpu 或者 mem 设置参数,那么也就是说即使改变了 cgroup 对于他们来说都无效,那么使用场景也就有限了
    **A8:**限制容器的资源使用这个还是有价值的。限制低优先级应用本身也可以提升高优先级应用的 SLO,虽然效果没有那么明显。稳定性的考量同样也很重要。

    **Q9:**Policy engine 目前在阿里的使用如何?在生产上有多上的规模使用这种方式进行动态调整?是否和社区的 HPA VPA 配合使用?
    **A9: **Policy engine 在阿里某些集群已经使用。至于规模暂时无法透漏。涉及到很多组件之间的联动,社区的 HPA 和 VPA 目前都不太能满足我们的需求。因此阿里的 HPA 和 VPA 都是我们自行开发的,但是和社区的原理是一致的。阿里 HPA 的开源可以关注 Openkruise 社区。VPA 开源计划我这里还没有确切消息。

    **Q10:**当单机节点资源不足以提供容器扩容时,目前是否可以进行 HPA 或 VPA 扩容呢?
    **A10:**单机节点不足的时候,应用可以通过 HPA 进行增加副本应对。但是 VPA 如果选择原节点进行更新的话,是失败的。只能调度到其他资源丰富的节点。在流量陡升的场景下,重建容器未必能满足需求,很可能导致雪崩,即重建过程中,整个应用其他未升级的副本接受更多流量,OOM 掉,新启动的容器再瞬间被 OOM,所以重启容器需要慎重。快速扩容(HPA)或者快速提升高优先级资源,抑制低优先级容器资源的方式效果更明显。

    关注『阿里巴巴云原生』公众号,回复关键词“1010”,可获取本文 PPT

    “ 阿里巴巴云原生微信公众号(ID:Alicloudnative)关注微服务、Serverless、容器、Service Mesh等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践,做最懂云原生开发者的技术公众号。”

    展开全文
  • 资源静态分配策略要求每个过程在开始执行前申请所的全部资源, 仅在系统为之分配了所的全部资源后,该进程才开始执行。这样, 进程在执行过程中不再申请资源,从而破坏了死锁的四个必要条件 之一"占有并等待条件...
    
    资源静态分配策略要求每个过程在开始执行前申请所需的全部资源,
    仅在系统为之分配了所需的全部资源后,该进程才开始执行。这样,
    进程在执行过程中不再申请资源,从而破坏了死锁的四个必要条件
    之一"占有并等待条件",从而防止死锁的发生。

     

     

    展开全文
  • 内存分配策略和分配方法

    千次阅读 2018-04-23 16:29:15
    2)物理块的分配策略;3)物理块的分配算法。1、最小物理块数的确定-- 这里所说的最小物理块数,是指能保证进程正常运行所的最小物理块数。-- 当系统为进程分配的物理块数小于此值时,进程将无法运行。-- 进程应...

    点击打开链接

    ----- 在为进程分配内存时,将涉及到3个问题:

    1)最小物理块数的确定;2)物理块的分配策略;3)物理块的分配算法

    1、最小物理块数的确定

    -- 这里所说的最小物理块数,是指能保证进程正常运行所需的最小物理块数。

    -- 当系统为进程分配的物理块数小于此值时,进程将无法运行。

    -- 进程应获得的最少物理块数与计算机的硬件结构有关,取决于指令的格式、功能和寻址方式

    2、物理块的分配策略

    -- 在请求分页系统中,可采取两种内存分配策略,即固定可变分配策略。在进行置换时,也可采取两种策略,即全局置换局部置换

       于是可组合出以下三种适用的策略。

    1)固定分配局部置换(Fixed Allocation,Local Replacement)

    ---- 这是指基于进程的类型(交互型或批处理型等),或根据程序员、程序管理员的建议,为每个进程分配一定数目的物理块,在整个运行期间

    不再改变。采用该策略时,如果进程在运行中发现缺页,则只能从该进程在内存的n个页面中选出一个页换出,然后再调入一页,以保证分配给该

    进程的内存空间不变(固定分配)。

    ---- 实现这种策略的困难在于:应为每个进程分配多少个物理块难以确定。若太少,会频繁地出现缺页中断,降低了系统的吞吐量;若太多,又必

    然使内存中驻留的进程数目减少,进而可能造成CPU空闲或其他资源空闲的情况,而且在实现进程对换时,会花费更多的时间。

    2)可变分配全局置换(Variable Allocation,Global Replacement)

    这可能是最易于实现的一种物理块分配和置换策略,已用于若干个OS中。在采用这种策略时,先为系统中的每个进程分配一定数目的物理块,而

    OS自身也保持一个空闲物理块队列。当某进程发现缺页时,由系统从空闲物理块队列中取出一个物理块分配给该进程,并将欲调入的(缺)页装

    入其中。这样,凡产生缺页(中断)的进程,都将获得新的物理块。仅当空闲物理块队列中的物理块用完时,OS才能从内存中选择一页调出,该页

    可能是系统中任一进程的页,这样,自然又会使那个进程的物理块减少,进而使其缺页率增加。

    3)可变分配局部置换(Variable Allocation,Local Replacement)

    这同样是基于进程的类型或根据程序员的要求,为每个进程分配一定数目的物理块,但当某进程发现缺页时,只允许从该进程在内存的页面中选出

    一页换出,这样就不会影响其它进程的运行。如果进程在运行中频繁地发生缺页中断,则系统需再为该进程分配若干个附加的物理块,直至该进程

    的缺页率减少到适当程度为止;反之,若一个进程在运行过程中的缺页率特别低,则此时可适当减少分配给该进程的物理块数,但不应引起其缺页率

    的明显增加。

    ---- 全局是指置换页面时,换出的页面可能是内存中的任一进程的页面,局部只能是本(缺页)进程的页面。

    ---- 固定分配指为一个进程分配的物理块是固定的,可变分配指可根据缺页率调整所分配的物理块数。

    3、物理块分配算法

    -- 在采用固定分配策略时,如何将系统中可供分配的所有物理块分配给各个进程,可采用下述几种算法。

    1)平均分配算法

    -- 这是将系统中所有可供分配的物理块平均分配给各个进程。例如,当系统中有100个物理块,有5个进程在运行时,每个进程可分得20个物理块。

    这种方法看似公平,实际不然,因为它未考虑到各进程本身的大小

    假如有一个进程大小为200页,只分配给它20个块,它必然有很高的缺页率;而另一进程只有10页,却有10个物理块闲置未用。

    2)按比例分配算法

    -- 这是根据进程的大小按比例分配物理块的算法。如果系统中共有n个进程,每个进程的页面数为Si,则系统中各进程页面数的总和为:

        S=S1+S2+...+Si+...+Sn-1+Sn (i=1~n)     又假定系统中可用的物理块总数为m,则每个进程所能分到的物理块数为bi,则有:

        bi=(Si*m)/S   其中,b应该取整,它必须大于最小物理块数。

    3)考虑优先权的分配算法

    -- 在实际应用中,为了照顾到重要的、紧迫的作业能尽快地完成,应为它分配较多的内存空间。通常采取的方法是把内存中可供分配的所有物理块

    分成两部分:一部分按比例地分配给各进程;另一部分则根据各进程的优先权,适当地增加其相应份额后,分配给各进程。

    在有的系统中,如重要的实时控制系统,则可能是完全按优先权来为各进程分配其物理块的。

    4、调页策略

    ---- 预调页策略和请求调页策略

    ---- 确定从何处调入页面

    请求分页系统中的外存分为两部分:文件区对换区(用于存放文件的文件区和用于存放对换页面的对换区)。

    通常,对换区采用连续分配方式,文件区是采用离散分配方式。故对换区的磁盘I/O速度比文件区的高。何处调入分3种情况:

    -- 1)系统拥有足够的对换区空间,可全部从对换区调入所需页面。在进程运行前,需将与该进程有关的文件从文件区拷贝到对换区。

    -- 2)系统缺少足够的对换区空间,不会被修改的文件都直接从文件区调入,当换出这些页面时,由于它们未被修改而不必将它们换出,以后

    再调入时,仍从文件区直接调入。对于那些可能被修改的部分,在将它们换出时,需调到对换区,以后需要从对换区调入。

    -- 3)Unix方式。凡是未运行过的页面,都应从文件区调入。曾经运行过但又被换出的页面,放在对换区,调入时从对换区调入。Unix系统运行

    页面共享,因此某进程所请求的页面有可能已被其它进程调入内存,此时无需再从对换区调入。

    展开全文
  • 内存分配策略和分配算法

    千次阅读 2016-06-22 12:13:29
    2)物理块的分配策略;3)物理块的分配算法。 1、最小物理块数的确定 -- 这里所说的最小物理块数,是指能保证进程正常运行所的最小物理块数。 -- 当系统为进程分配的物理块数小于此值时,进程将无法运行。 -- 进程...

    ----- 在为进程分配内存时,将涉及到3个问题:

    1)最小物理块数的确定;2)物理块的分配策略;3)物理块的分配算法

    1、最小物理块数的确定

    -- 这里所说的最小物理块数,是指能保证进程正常运行所需的最小物理块数。

    -- 当系统为进程分配的物理块数小于此值时,进程将无法运行。

    -- 进程应获得的最少物理块数与计算机的硬件结构有关,取决于指令的格式、功能和寻址方式

    2、物理块的分配策略

    -- 在请求分页系统中,可采取两种内存分配策略,即固定可变分配策略。在进行置换时,也可采取两种策略,即全局置换局部置换

       于是可组合出以下三种适用的策略。

    1)固定分配局部置换(Fixed Allocation,Local Replacement)

    ---- 这是指基于进程的类型(交互型或批处理型等),或根据程序员、程序管理员的建议,为每个进程分配一定数目的物理块,在整个运行期间

    不再改变。采用该策略时,如果进程在运行中发现缺页,则只能从该进程在内存的n个页面中选出一个页换出,然后再调入一页,以保证分配给该

    进程的内存空间不变(固定分配)。

    ---- 实现这种策略的困难在于:应为每个进程分配多少个物理块难以确定。若太少,会频繁地出现缺页中断,降低了系统的吞吐量;若太多,又必

    然使内存中驻留的进程数目减少,进而可能造成CPU空闲或其他资源空闲的情况,而且在实现进程对换时,会花费更多的时间。

    2)可变分配全局置换(Variable Allocation,Global Replacement)

    这可能是最易于实现的一种物理块分配和置换策略,已用于若干个OS中。在采用这种策略时,先为系统中的每个进程分配一定数目的物理块,而

    OS自身也保持一个空闲物理块队列。当某进程发现缺页时,由系统从空闲物理块队列中取出一个物理块分配给该进程,并将欲调入的(缺)页装

    入其中。这样,凡产生缺页(中断)的进程,都将获得新的物理块。仅当空闲物理块队列中的物理块用完时,OS才能从内存中选择一页调出,该页

    可能是系统中任一进程的页,这样,自然又会使那个进程的物理块减少,进而使其缺页率增加。

    3)可变分配局部置换(Variable Allocation,Local Replacement)

    这同样是基于进程的类型或根据程序员的要求,为每个进程分配一定数目的物理块,但当某进程发现缺页时,只允许从该进程在内存的页面中选出

    一页换出,这样就不会影响其它进程的运行。如果进程在运行中频繁地发生缺页中断,则系统需再为该进程分配若干个附加的物理块,直至该进程

    的缺页率减少到适当程度为止;反之,若一个进程在运行过程中的缺页率特别低,则此时可适当减少分配给该进程的物理块数,但不应引起其缺页率

    的明显增加。

    ---- 全局是指置换页面时,换出的页面可能是内存中的任一进程的页面,局部只能是本(缺页)进程的页面。

    ---- 固定分配指为一个进程分配的物理块是固定的,可变分配指可根据缺页率调整所分配的物理块数。

    3、物理块分配算法

    -- 在采用固定分配策略时,如何将系统中可供分配的所有物理块分配给各个进程,可采用下述几种算法。

    1)平均分配算法

    -- 这是将系统中所有可供分配的物理块平均分配给各个进程。例如,当系统中有100个物理块,有5个进程在运行时,每个进程可分得20个物理块。

    这种方法看似公平,实际不然,因为它未考虑到各进程本身的大小

    假如有一个进程大小为200页,只分配给它20个块,它必然有很高的缺页率;而另一进程只有10页,却有10个物理块闲置未用。

    2)按比例分配算法

    -- 这是根据进程的大小按比例分配物理块的算法。如果系统中共有n个进程,每个进程的页面数为Si,则系统中各进程页面数的总和为:

        S=S1+S2+...+Si+...+Sn-1+Sn (i=1~n)     又假定系统中可用的物理块总数为m,则每个进程所能分到的物理块数为bi,则有:

        bi=(Si*m)/S   其中,b应该取整,它必须大于最小物理块数。

    3)考虑优先权的分配算法

    -- 在实际应用中,为了照顾到重要的、紧迫的作业能尽快地完成,应为它分配较多的内存空间。通常采取的方法是把内存中可供分配的所有物理块

    分成两部分:一部分按比例地分配给各进程;另一部分则根据各进程的优先权,适当地增加其相应份额后,分配给各进程。

    在有的系统中,如重要的实时控制系统,则可能是完全按优先权来为各进程分配其物理块的。

    4、调页策略

    ---- 预调页策略和请求调页策略

    ---- 确定从何处调入页面

    请求分页系统中的外存分为两部分:文件区对换区(用于存放文件的文件区和用于存放对换页面的对换区)。

    通常,对换区采用连续分配方式,文件区是采用连续分配方式。故对换区的磁盘I/O速度比文件区的高。何处调入分3种情况:

    -- 1)系统拥有足够的对换区空间,可全部从对换区调入所需页面。在进程运行前,需将与该进程有关的文件从文件区拷贝到对换区。

    -- 2)系统缺少足够的对换区空间,不会被修改的文件都直接从文件区调入,当换出这些页面时,由于它们未被修改而不必将它们换出,以后

    再调入时,仍从文件区直接调入。对于那些可能被修改的部分,在将它们换出时,需调到对换区,以后需要从对换区调入。

    -- 3)Unix方式。凡是未运行过的页面,都应从文件区调入。曾经运行过但又被换出的页面,放在对换区,调入时从对换区调入。Unix系统运行

    页面共享,因此某进程所请求的页面有可能已被其它进程调入内存,此时无需再从对换区调入。

    展开全文
  • 第3章 垃圾收集器与内存分配策略

    千次阅读 2013-11-17 11:26:56
    第3章 垃圾收集器与内存分配策略 本章主要内容 概述 对象已死? 垃圾收集算法 垃圾收集器 内存分配与回收策略 Java与C++之间有一堵由内存动态分配和垃圾收集技术所围成的高墙,墙外面的人想...
  • Java GC 机制与内存分配策略

    千次阅读 2016-11-10 00:00:07
    为什么我们要了解学习 GC 与内存分配呢? 在 JVM 自动内存管理机制的帮助下,不再需要为每一个new操作写配对的delete/free代码。但出现内存泄漏和溢出的问题时,如果不了解虚拟机是怎样使用内存的,那么排查错误将是...
  • 资源分配与调度

    千次阅读 2019-12-31 19:07:29
    2、在“合理”时间内使所有顾客有获得所需资源的机会; 3、不可共享的资源实施互斥使用; 4、防止由资源分配不当而引起的死锁。 对资源的管理应包括以下几个方面: 1、资源管理的描述--数据结构 2、确定资源的...
  • JVM:自动内存管理-垃圾收集器与内存分配策略

    千次阅读 多人点赞 2021-01-12 12:27:38
    JVM:自动内存管理-垃圾收集器与内存分配策略 Java与C++之间有一堵由内存分配和垃圾收集技术所围成的高墙,墙外面的人想进去,墙里面的人却想出来。 一、概述:Java堆和方法区这两个区域有着很显著的不确定性 二、...
  • 如果您更改安全设置和用户权限分配,则可能会导致客户端、服务和程序问题发生 适用于: Microsoft Windows Server 2003 Standard Edition (32-bit x86)Microsoft Windows Server 2003 Datacenter Edition (32-bit ...
  • 机场停机位资源分配优化题目描述https://tianchi.shuju.aliyun.com/outsource/offer/projectdetails.htm?spm=5176.8199929.0.0.nPvIru&id=3092成绩复赛:得分14.40,排行榜第一名; 决赛:第一名总体思路1、 求解...
  • 工作流管理中的一种资源管理策略

    千次阅读 2006-03-08 22:49:00
    工作流管理中的一种资源管理策略(http://blog.csdn.net/kingspider/)(http://blog.sina.com.cn/u/1163490885) 1. 引言 工作流管理是一个被业界广泛应用并迅速发展的技术,它的主要特点是使计算机上的处理业务...
  • JVM初探- 内存分配、GC原理与垃圾收集器

    万次阅读 多人点赞 2016-12-30 20:45:21
    JVM初探- 内存分配、GC原理与垃圾收集器 JVM内存的分配与回收大致可分为如下4个步骤: ...VM内存分配策略: 对象内存主要分配在新生代Eden区, 如果启用了本地线程分配缓冲, 则优先在TLAB上分配, 少数情况能会直接分配在
  • Spark集群的调度分应用间调度和应用内调度两种情况,下文分别进行说明。...根据应用对资源的申请需求为其分配静态的partition(s)是Spark支持的最简单的调度策略。 我们已经知道,不同的应用有各自的Spark C
  • Unity资源管理(四)-AssetBundle使用模式 参考文献:https://unity3d.com/cn/learn/tutorials/topics/best-practices/assetbundle-usage-patterns 本系列的前几篇文章讲述了AssetBundle的基本原理,包括几种...
  • 设备分配

    千次阅读 2017-10-08 09:34:07
    为防止诸进程系统资源的无序竞争,特规定系统设备不允许用户自行使用,必须 由系统统一分配。每当进程向系统提出I/O请求时,只要是可能和安全的,设备分配程序便按照一定的策略,把设备分配给请求用户(进程)...
  • 一、HAWQ如何管理资源 HAWQ使用多种机制管理CPU、内存、I/O、文件句柄等系统资源,包括全局资源管理、资源队列、强制资源使用限额等。...在YARN环境中,资源分配的单位被称为容器(container),YARN还
  • 操作系统中的进程调度策略有哪几种

    万次阅读 多人点赞 2018-09-22 09:00:39
    当在作业调度中采用该算法时,每次调度都是从后备作业队列中选择一个或多个最先进入该队列的作业,将它们调入内存,为它们分配资源、创建进程,然后放入就绪队列。在进程调度中采用FCFS算法时,则每次调度是从就绪...
  • 死锁的处理基本策略和常用方法

    千次阅读 2018-08-02 14:59:02
    解决死锁的基本方法如下: 预防死锁、避免死锁、检测...安全状态与不安全状态:安全状态指系统能某种进程顺序来为每个进程分配其所需资源,直 至最大需求,使每个进程都可顺利完成。若系统不存在这样一个序列, ...
  • nginx负载均衡的5种策略及原理

    万次阅读 多人点赞 2018-08-08 11:58:51
    每个请求时间顺序逐一分配到不同的后端服务器,如果后端服务器down掉,能自动剔除。  upstream backserver {  server 192.168.0.14;  server 192.168.0.15;  } 2、指定权重 指定轮询几率,weight和访问比率成...
  • 我的大学四年到毕业工作5年的学习路线资源汇总

    千次阅读 多人点赞 2020-03-31 13:37:10
    通过以往的学习和你自己知识栈的积累,以及在这条路上认识到的同好,基本你也是一个小大牛了,可以独立解决一些问题和一些知识有了自己的学习方法论。接下来这一年可以继续拓展自己的技能! 1. 软件 序号 软件 ...
  • 日期 内核版本 架构 作者 GitHub CSDN 2016-06-14 ...1 前言1.1 进程调度内存中保存了每个进程的唯一描述, 并通过若干结构与其他进程连接起来.调度器面对的情形就是这样, 其任务是在程序之间共享CPU时间, 创
  • 动态分区分配算法 ...当用户提出申请存储器空间时,存储管理必须根据申请者的要求,一定的策略分析主存空间的使用情况,找出足够的空闲区域分配给申请者。当作业撤离或主动归还主存资源时,则存储
  • 全面了解风控策略体系

    万次阅读 多人点赞 2020-06-28 14:09:48
    模型和策略的开发是一个系统工程,这其中需要有业务经验、统计理论、算法运用、和数据认知,是一个不断反思,不断积累经验的过程。沙滩上建不起摩天大楼。扎扎实实的基本功永远有价值,永远不会过时。
  • 在使用管线结构的时候应该意识到,如果不能最慢的阶段进行进一步优化,就要使其他阶段与最慢阶段的工作负载尽可能一样多(也就是既然都要等瓶颈阶段,不妨给其他阶段分配更多任务来改善最终的表现,反正是要等)。...
  • Hadoop-YARN的资源调度

    千次阅读 2019-04-10 19:38:36
    YARN 是一个资源调度平台,负责为运算程序提供服务器运算资源,相当于一个分布式的操 作系统平台,而 MapReduce 等运算程序则相当于运行于操作系统之上的应用程序 YARN 是 Hadoop2.x 版本中的一个新特性。它的出现...
  • Apache Hadoop YARN (Yet Another Resource Negotiator,另一种资源协调者)是一种新的Hadoop 资源管理器,它是一个通用资源管理系统和调度平台,可为上层应用提供统一的资源管理和调度,它的引入为集群在利用率、...
  • Android性能优化策略

    千次阅读 2016-05-30 10:39:46
    本篇主要是 google推出的性能优化典范 进行一个通篇的整理… 主要在于一些具体的优化技巧、至于 60fps、掉帧、gc、内存抖动、阈值…等等这些性能术语的概念里面不做多概括,请自行查阅…本篇从以下几点延伸扩展… ...
  • 死锁,死锁的四个必要条件以及处理策略

    万次阅读 多人点赞 2018-03-19 16:57:02
    3.1 可重用资源和消耗性资源 3.1.1 可重用资源(永久性资源) 3.1.2 消耗性资源(临时性资源) 3.2 可抢占资源和不可抢占资源 3.2.1 可抢占资源 3.2.2 不可抢占资源 四、死锁产生的原因 4.1 竞争不可抢占资源...
  • Oracle资源管理器在HIS系统中的应用

    千次阅读 2014-03-20 17:02:15
    导致整个HIS系统的操作变慢甚至影响正常业务使用的情况,其实这是典型的服务器资源争用和等待的案例,如何合理的分配和管理有限的服务器资源,让更重要的业务更充分的利用资源,这是本文Oracle资源管理所实现的功能...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 61,585
精华内容 24,634
关键字:

对资源采用按需分配的策略