大家好,很高兴在这里能给大家分享一下我们的一些经验教训然后这也是最后一场骷髅汉的演讲然后感谢大家能来今天我们主要介绍的这个主题就是如何让炮的启动速度能够更快尤其是在一些大规模的集群里面我叫徐俊杰,帕口徐,然后来自Docloud然后我主要在做的是Signal的跟CruidM相关的事情大家好,我叫王柏妍然后现在主要的工作在调度器和AI Ops相关的事情首先这个问题其实我在很久之前做一些on call的时候会被问到就是说我的炮的启动慢,然后怎么办然后我当时就一直在想这个问题就是为什么这个炮的启动是很重要的其实我觉得简单来说就是你一个好的开始是一个成功的一半见识中也是这样子就是在你的炮的它很多的问题可能都是在它启动的短的周期内的一个问题而它后面稳定运行以后其实它的问题就不会太多了包括Cruid包括其他的各个组件的配合的东西就会其实就少很多其实这个启动这个过程还是非常值得大家去深入研究的那么怎么来做呢就是我之前把这个问题拋到了那个Reddit上然后就就一个人上来就回答了我一个这个这个方法就是说把你的那个Reddit的速度就会比以前快很多然后这个是有点搞笑的方法然后下面的人就开始更夸张了就是说那我是不是可以编辑一下我的启动时间呢自己那肯定是不行吧然后下面的人更离谱说那我能不能编辑一下我的工资吗作为银延生开发工程师我们如果能自定义自己的工资可能是大家的理想吧然后划规正转就是那其实这个问题是有一点不严谨的就是说你怎么启动更快那首先你快不快你怎么去判断这是一个问题就是说你多快算是快或者说你的正常的一个炮的应该是能启动多久然后这里呢我简单列了一下其实不同的这个炮的它启动的速度呢其实是不一样的这是ChillGVT给我的一个答案我仔细看了一下其实感觉比我想的还要好一点就是其实就是你有些轻量级的炮它启动速度可能在50毫米以内但是其实到了一些就是比较重的然后需要很多results的然后还是很大的那种镜像的还有一些就是这种网络的问题的它的启动速度可能就不会那么快了可能会到分钟级当然大部分的炮的其实我个人认为应该是在秒级就是或者是好秒级这个是应该一个比较正常的范围内如果你results比较多可能也尽量不能超过一分钟就通常来说可能这是一个就是common的一个状态下今天我们的主题分享呢其实是分了这么几个模块然后就是炮的的创建它的速度它的调度的情况还有它的那个在几点上启动的情况最后是一个怎么去观测它的这个过程然后有一些可观的性的东西这里重点呢我们会在调度和那个节点启动这两个模块首先呢就是炮的起动其实你的炮的首先你要知道它是从哪里创建的是一个controller创建的还是一个operator创建的还是一个其他的什么比如 static pod 或者是什么去创建的这个创建过程呢它其实是要去API server去有一个操作的除了那个 static pod的然后那API server的速度就决定了你的这个pod的创建的速度那这个问题其实也是一个大家比较常见的就是你的edcd的速度你的edcd的load然后还有你的那个API server这边的一个read limit是不是达到然后这几个其实相对来说可能更多的需要你去调优API server和edcd还包括这个磁盘但是还有一个问题就是那个webhook其实有些webhook它确实比较慢会严重影响你的这个创建速度这个是我们可能需要避免的另外一个点就是刚才提到的这个controller和operator它在创建这个pod它可能会有一个从事的机制在里面所以有可能是因为你的前面会有一些创建错误或者是validation的一些feature导致着你的这个最终的启动速度变慢然后这里其实提到了webhook然后validation然后包括你的resource的quota这些东西我们有达到你的name space的quota你的这个整个资源池的一个大小其实这里的话如果真的你想去做一些强制的加速那你只能用这种抢占式的调度或者是一些其他的方案来去做所以这块可能更多的一个是你API server跟EDCD的性能问题另外一个是你的webhook这块的一个控制下面介绍一下调度调度其实这里是先讲一下就是一个简单的一个调度场景或者一个常规的一个调度器它需要去做的事情就是如果你的pod是没有指定node的话那它就会通过调度器来去做一个调度然后这里面其实比较常见的一个是规模问题一个是你的失败问题就是你的调度里面它其实是有这种retry的能力的所以你看到它调度满不一定是调度器满有可能是你的调度的条件没有达到这时候你要去找这些失败的原因还有就是你的节点比较多的情况下调度器可能在有一些情况下它在计算或者什么的会比较慢另外就是你是不是加了一些合适的node affinity然后来帮助它调度的更快和更准确这也是很重要的另外一个就是同一时间你创建的pod数量在有一些很大规模的情况下它的同一时间创建很多pod的时候也会严重影响它的一个调度时间这块可能需要具体的看你的平景在哪里然后做一些调忧除了你调度器本身的调度速度你还要考虑一个点就是说它调度的节点是不是压力大所以现在其实会有些人有这种需求就是load aware的需求就是它去load aware其实就是每个节点上它要看它的load看它的一些其他的资源的使用情况然后得出一个就是说哪些节点它调度下来它启动会更快或者说我们如果基于这个方案的话其实你就会让你的pod调度到一个load更小的一个节点上然后后面一个的话其实就是说的你的分散性你分散开调度的话同一时间调度到一个节点上的pod不够没有那么多那你的启动速度也会能够上来一点然后关于AI的是由薄言来介绍因为我现在最近在做很多事情其实都是跟GPU相关的然后这里面就是在这一节我会主要给大家讲一下我如果一个pod在申请一个设备或者是申请一个GPU的时候它大概的一个流程或者是我们要添哪些东西在一个压谋里面左边这个就能看到就是这是一个最简单的一个pod这样的一个压谋然后我们只需要在resource里面然后添上一个map 对吧这是一个stream int这样的一个map我们就添上去然后这样的代表我们要向系统去申请这样的一个GPU资源当然这个地方当然它不是KBS的本身带的其实你在这个世界上任何一个设备你都需要有一个device plug-in这样的机制去把你的一个设备去注册到这个节点上面通过cruelite的socket的接口所以它主要的分为两个大部分一个是在note上面它涉及到的就是设备的注册以及设备的一个分配然后在pod的阶段当然它要申请然后申请之后等到pod真正的被调度器调度到然后它已经拥有了使用这个设备的权力之后然后它进行一次真正的分配然后到最后pod完成了它的整个生命周期然后这个设备这个声明再被回收掉整个这样的就是KBS的一个最简单的也是目前所有的device一个你自己的设备接入到KBS这样的一个流程然后但是因为device plug-in的接口是非常非常早的它是1.8版本就有的而且这个接口一直到现在都没有变化它其实是存在这些问题的因为KBS的本身呢它也不是为一个eGo的一个资源设计的这样的一个变拍系统它更多的还是考虑的是CPU memory跟硬盘这样的一些资源就是这里面的最带来了最明显的问题首先第一个就是如果我的设备它的个数或者是它的某些属性发生了一些改变这个其实在fpa-z这样的一个场景内会比较容易发生但是比如说在GPU的场景下因为我插在服务器上就直接卡除非我重启上面的我的device plug-in否则它的设备数量是一定不会变化的但是这个还好然后但是比较麻烦的是在于接下来的一些事情就像我如果我是同一家厂商的不同类型的设备那我就要去注册两种资源大家可以先看上一张这边这边弄话我前面这是我们的厂商后面代表这类型包括你在用比如说invada的GPU device plug-in也是一样的你要添一个invada.com然后GPU资源你是不能够区分这是一张3090还是一张A版还是一张什么其他型号的卡因为每张卡它提供的算力跟功能其实它是非常不一样的然后它的售价它的成本它都是不同的所以你从最基础的device plug-in的角度你是没有办法对这些去做区分的然后再一个事情就是如果我有多个不同来自多个厂商的设备在一个集群里的时候我就需要有无数个device plug-in如果我拥有2DMA的设备那我需要一个2DMA device plug-in我要用另一家显卡比如说我这个集群可能是一个混布的显卡它既有invada的卡又有AMD的卡又有别人的卡那我就要device plug-in每一台机场然后就有附属个人然后还有一件事情的就是这里面的分配当前device plug-in的接口它只能够把设备分配给一个pout的它是不能够支持把一个设备分配给多个pout的还有就是我分配一个节点的时候比如说我一个台机器上有8转卡8转卡分处于两个CPU下面那么我不能够指定说我要分配0号卡或者是我要分配指定的7号卡我只能由corporate它自己去给你决定一个当前有一个没有分配的卡那就决定是你了就是这样的一个形态你没有办法去做任何样的控制然后对然后这里面的问题的话我会在接下来的那一节中然后给大家简单分享一下我们在遇到这些问题的时候的一些解决方案然后在此之前先看一下就是在一个GPU的一个调度场景里面常用的一些算法跟策略以及首先这个GunGun的策略其实它是很简单的我默认的调度器它是以所有的调度逻辑都是以POD为最小的单位的就是POD成功那就结束然后继续下一个POD所有的设计逻辑也是但是实际上在一个基学系的这样的一个场景之下有的时候我是需要一个分布式训练的我可能需要多个POD同时协作才能够完成所以我需要有一个类似于POD Group或者是Gun这样的一个策略来保证我的所有任务要么完成全都要么成功调度那么就这个任务才可以真正的调度起来如果有一个任务调度不起来那么我的任务就会调度失败然后去继续等待然后第二个这边就是SGO其实这个SGO描述的不是特别精准但是我一直没有给它想到一个很好的名字它强调的是一个是按比例分配比如说我的物理机上面的配置它的CPU、Memory、GPU这样的它们是存在一定的比例关系的如果我申请的资源每一份资源都是按照一个这样最低的最基础的公优数的比例去分配那么意味着我的资源碎片会有一个非常小的我只会有一个非常小的资源碎片而且这个资源碎片它也是符合这个比例的就像这张图上面它就像一个PISA一样我们去分PISA的时候它总是把它分成均等的份不会像右边这样我们就是随便的去切一刀然后再随便的切一刀因为剩下的是不规则的不规则的就意味着它有可能或者是它会有更大的概率是没有办法去填满整个空间的然后对这样的话其实在CPU跟比如在我们存CPU的这种场景下其实还好CPU嘛对吧本身就是分片的其实浪费一点也不重要但是其实在一个带有GPU的场景下它是非常不划算的因为GPU的价格非常的高然后它的成本是非常非常高的那么如果我有一个任务它把这台机器上那边的所有CPU都占满了但是GPU一个没有用那么意味着其他的所有的任务都所有要用GPU的任务也不能够调度上来那我的这个GPU就会彻底地空跑就是造成一个非常大的浪费然后接下来是就是BIMPACBIMPAC它这个调度算法其实原理上也非常简单就是它会尽可能的填满整这个尽可能的填满机器而不是将它分散在不同的节点上其实这个和SPU这样的想法其实都是一致的就是我要尽可能的把资源利用满然后不要让资源去有大量的控语尤其是不要让GPU有控语然后是DFDF就是Dominator Results Fairness它是一种最大化最小公平算法它能够保证说我在集群里面的每一个用户它都是尽可能的公平的拥有一份最小的资源我尽可能地保证每一个用户相对公平就实际上换到实际的实现就是一种最简单的基础实现就是我让小的任务拥有更高的优先级或者说我让小的任务在我在排序的时候我会尽量地把它往前排然后保证小的任务不会饿死不会让一直是大的任务去抢占所有的资源而让小的任务可以有机会去占用到我们的资源好的刚才我们其实介绍的是调度这一块可能刚才DRA后面在note启动这块还会有继续的介绍然后是在极点上启动一个note的其实这个过程是比较复杂的可能这张图比较不太清晰可能后面可以我在传到哪里它其实讲的是一个pod的创建然后这边是创建流程这边是它的webhook这边是它的pending的调度然后到它的running然后下面是它的prob的情况就startupprob跟它的runis跟livenessprob包括你还可以在这个过程里面去exgc还有它会有一个postart跟prestop的一个hook此外的话除了我们的在创建过程中有个sandboxsandbox会有一个seni的准备然后后面会有一个init container当然这个sidecard的变化这个其实我还没有去修改然后是它的主要的container和它的sidecardcontainer还包括一些临时容器这是它的整个生命周期和它的状态变化其实我们在看它的启动过程的时候其实也是从整个流程里面去想哪里是它的平顶点去哪里去优化首先我举一个简单例子就比如说你现在遇到了一个问题就是你的启动速度要慢那么怎么样简单的去理解这个问题呢其实它的最主要的四个步骤就是拉进向seni的sandbox启动然后它的volume的mount然后最后它的主要的一个进程的启动所以其实从这个角度的话那我再去定位问题的时候我可以尝试比如说先把进行卡拉好那我的启动速度变快了那可能平仅就在这个铺进向的这个过程然后我可以尝试把hostnetwork配起来那这样子如果它变快了那可能seni这块是不是存在一些问题还有就是volume不加volume mount然后或者是我把cpu和memory的一些limitation去掉然后这其实是让一个就一个简单的让pull的启动变快的办法但是当然很多时候我们不能这样做然后我后面会挨个去介绍各个方向就比如说你的进向比较大那你拉进向比较慢其实进向大是一个比较常见的原因或者是当然你进向仓库曼也是一种然后进向大的这个其实我这边只是列了一些最简单的一些tip就是你在创建的时候不要去就去加那个darkrack null然后来去防止一些不应该加进来的一些文件加进来然后包括你可以用一些最小的机组经向用多不勾件或者是你的layer去做一个scrunch然后来让你的进向更小另外就是这里有一个比较简单的一个就是建议就是说你不要把一些debug的tool放进去然后现在因为cork control debug也挺好用了另外就是你可以通过debug的进向的t换或者是一些其他方式来去做这种叫什么调识最后一个的话其实是讲的它有一个这是个算是一个拓展阅读这个小工具它可以帮你解析你每一层的进向是什么东西当然你也可以用其他的一些工具当然大进向有些时候是无法避免的就像现在的AI其实我们可能可以用常识P2P的方式或者是Layers A Pulling的方式昨天其实也有Dragonfly的一些主题然后大家如果可以后面也可以听然后就是通过这种P2P的方式来加速你的进向下载其实这个效果都是很好的懒家载的话目前可能地这边应该也有多种的一种驱动可以使用了另外一个就从cruelette的角度就是你去并行去拉取进向这个其实也能够在多个炮的同时启动的时候来起到一点效果但是目前其实它也存在一个问题就最近也在提就是它一个炮的里面有多个进向的时候它也是多个进向是那个串形去拉的所以会比较慢这块其实我们可能也会后面去做调整但是这个还没有进来然后现在能做的事情就是你多个炮的并行的去做一个拉取然后现在我们在1.27加了一个功能就是max最大的一个并行下载的数量这个建议目前的话也不会太高因为太高的话可能就如果你并行下载的数量太高的话又可能导致你的吃白崩溃这块的话会不太好就是会就造成事故了那就不太好了然后这块可能刚才提到P2P里面昨天也请教了一下Dragonfly的mentender他们其实在Dragonfly里面它会有一个限数可能D里面的话据说也是有在做一个限数的就是防止你的磁盘最后崩掉的这种情况所以这块可能会越来越好另外一个就是你的init container你现在的炮的里面有没有这种init containerinit container的话它其实我目前觉得就是很多时候你可能要把一些很必要的事情放在里面或者是让这些事情如果能并发的话就并发去做因为现在的话它可能串形去做的话这个效果就会差很多而且它是在你的组容器启动之前去运行完之后才会启动你的组容器所以其实你要想一下就是说在init container里面做的事情能不能放到进行构建里面去做到或者是能不能放到一个Dreamset里面去把它在极点上就做掉了这样子就能节省出来这部分时间或者刚才这里提到的PosterStart hook可以在你组进程启动的同时去启动然后只是在Start之后启动是不是能够满足你的需求这也是能够提升你的启动速度的一个方法最近的VPA它合进去以后其实VPA这块的应用场景还是挺多的其中一个比较重要的场景就是我之前也遇到过就是Java它有一个比如说0.5核的限制那在0.5核的情况下它的启动速度会超级的慢所以就会有人提出用VPA的这种方案就是我在启动的时候给它配置两CPU它的启动就会能够比之前要快很多然后等到它启动完成了Reddit了那我就通过VPA把它修改成0.5核那这样它就既启动快了同时它也没有占用更多的资源这个方案还是将来可能会有更多的一些用的地方另外一个就是你想你的炮的它的启动速度更快有可能就防止就其实前面一个一场在讲隔离的一些东西其实这里就涉及到一个CPU的隔离那如果你能够做到绑合的话静态的一个CPU的Policy的话其实你也能够让你的炮的启动速度更稳定这里列了一下它的一个启动过程可能需要你去重启Corelight之前要去清理一个文件另外的话这里还可以提一个注意的点就是如果你的主容器本身是Garantee的但是你的Sidecar不是Garantee的这时候这个Policy是不会被使用的只有你的整个的是Garantee的才会被使用Prob这块的话就一个重点就是你的StartupProb要设置得合理一点因为它的到Ready是要等到它的Ready去成功一次而在之前它会等这个Startup如果之前没有Startup的话有可能你的Initial Delay的Seconds也可能会影响你的启动时间但是这个通常可能需要你做一个调整然后另外一个就是社区里在推的一个设计就是他们之前因为定义比较粗就是按秒来算的将来可能会按好秒算但是这个还在推进总还没有合计就它的设计还没有合计去所以可能还要比较久另外一个就是你现在可能也很多人在用这种日前移快照其实快照在这个启动过程中有一个小的用处就是说你如果你的启动是需要加载很多内存很多信息然后启动流程有很多预热的过程那你其实用这种快照的方式可以能够提升一点点你的启动速度这个在1.25已经可以做打包然后现在最新的版本里面应该可能需要借助一点点代码的工作才能完全用起来其他的一些原因比如说你现在的Runtime本身这个其实目前来说也就是Docker可能逼着切换或者是一些就是你减小你的调用链然后让它启动更快或者你的CNI这块其实大部分CNI像卡利口它在节点的分配的时候已经是在本地独立做了然后很快但是有些CNI它可能涉及到整体的一个规划或者网段规划之类的可能会有一些就会导致它变慢其实这块也是一个点剩下的就是1.27的这个还是挺重要的就是如果你还没有升级到1.27你的Cooplight默认配置其实是API的10和API QPS是5在这种情况下你的节点如果达到比如说几十个炮的或者是接近100个炮的时候你的炮的启动速度会严重受到影响因为这个是因为你Cooplight跟API server之间的访问会受到一个限制而在1.27以后被放大了10倍所以基本上不会有影响的所以如果你在老版本遇到一些比如说Mount Timeout或者一些其他的一些常见错误的话很可能是这个导致的另外一个就是我们上午Signal那边提到的Eventy的POE计Eventy的POE计其实也是在刚才说的一个节点上它管理的炮的比较多的情况下它会让Cooplight的效率更高然后从这种状态下你的炮的Reddit展示出来的时间可能就会更快然后这个就是其实刚才那个帕克也在说我们在新的版本中比如说在1.26然后引来的DRA然后1.27中它现在还是一个Alpha的一个阶段然后DRA能做的一个事情呢它本质上就是一个Device Plug-in 2.0它是一个超级加强版的一个Device Plug-in它就来解决它能解决的事情其实就是我刚才提出的这些问题比如说去解决更多的厂商厂商之间有不同的设备然后设备数量的改变然后以及说我不同的设备有一些需要特殊的拆输去虚拟化或者是一些我需要通过网络才能去夹载的一些设备然后但是DRA现在有一些现在还会有一些影响的问题一个事情是因为它现在还是需要跟APSOS去打交道然后它也去获取到一些必要的信息所以会降低整个炮的调度的这样的一个速度然后还有一个事情是原来我们只需要一行就可以做完申请一个设备但是现在我们需要写不少的一个亚本文件然后DRA这边不是我这次主要讲的点然后因为今年在EU的已经有人已经详细的讲过DRA的一些实现以及如何去实现一个最简单的然后大家有兴趣可以直接去看EU的那个录像然后这里面我们就说说完GPU管理的话我们要有几种方式如果说我们由于Divise Planning的限制然后我们不能够实现我们自己的功能那么肯定这是一个普世性的问题而且是一个由来已久的一个问题所以我们肯定需要做出一些事情来达成我们的目的那么第一条路就像说我们需要有一个新的Round Time就像英伟达Continual Round Time这样做的对吧比如说我们在一个英伟达机器里我们要去申请一张卡首先我们要去改Continuality Pages我们要把它默认的Round Time换成一个英伟达的Round Time这是一种办法然后还有一种办法就是我们去做一个CRA Proxy就类似于阿里有一个Cartinator那个项目它就可以说我在每个机器上都有一个proxy当我的请求在我的请求由Cruelite发给CRA之前先走一次我的proxy我的所有的处理逻辑在我的CRA Proxy这层做完我到底下实际的无论是到Round Time或者是到其他的Round Time这已经是我包装好过后的这样的话所有的Device信息自然我是可以控制的然后还有一种办法对吧我们可以改Cruelite的代码对然后还有就是DRA就是新版本我们要更新到一个比较新的版本才能带来然后以及引入的一个新的概念Continual Device Interface对CDI又一个CHI然后这里面就简单说一下这是我们团队做的一个东西因为我们在做这个东西的时候还比较早社区的CAP还没有提出来也就是还没有DRA的时候然后我们是怎么样去解决这件事情的就是我们没有足够的人力去做一个CRI的proxy我们首先是我们自定义了几个资源其中一个叫做GPU类型的资源GPU的类型的资源是与物理设备一对一匹配的你有几个物理设备我们的一个agent在启动的时候就会向API solar去上报我有多少GPU当然这个GPU它更复杂它包括了比如说PCID纸它是什么类型的它来自哪一个厂商然后以及它的脱谱关系是什么样子的我们都会上报上去然后这完成了上报的第一步然后当泡的去申请一个GPU的时候它除了要添写一些原来的一些参数之外它还要再创建一个叫做GPU banding的这样的一个资源然后GPU banding是一个连接GPU跟泡的这样的一个关系我们有一个它的类可以类比于pvc然后GPU就可以类比于pv大家可以简单理解这样的一个结构所以GPU banding在分给泡的时候实际上它是不知道要真正的绑定哪个泡子的时候这只是一份声明它只是说我需要一个我需要几个什么类型的GPU然后它会去发给的调度器然后没有一套自己的一个调度器的实现然后这里面主要先说这里面有一个前提的一个条件就是Device Poly里面的接口它主要的接口涉及到分配的有两个叫做lockade 一个叫做pre-startlockade就是在调度阶段去做它决定了哪台机器可以被调度哪台机器不能就是哪台机器有这个设备符合这个条件的设备哪个机器没有然后另一个是pre-startpre-start是真正的在泡的启动前负责去我进行挂载设备进行处置化这样的一个接口这就是Device Poly提供的仅有的两个接口所以我们还记得我们之前提过的这样的一个目标我们需要指定设备分配于是我们在lockade的阶段的时候我们永远都告诉Device Poly里面我们永远都有足够数量的我们每分配出去一个我们就又加一个因为我们给它分配的是一个假的设备然后我们会在一个待物下面的一个fake device下面去创建了这样的一个另一个文件等到实际的GPU通过了调度器就是我们发现了这个泡在调度中而且它还有GPU banding它GPU banding还没有指向相应的GPU的时候我们就会给它尝试去找符合它条件的GPU然后决定它是哪一台机器上的哪张卡于是在这个时候我们就可以做到各式就是我们就可以在这个调度中我们就可以做到各式各样的事情比如说做跳谱做拓谱做卡间的拓谱做机器之间的拓谱以及更多的更复杂的这样的分配因为我们可以决定它要的是哪台机器哪张卡当我们给它指定了机器之后下一步是给它分卡于是我们会还记得那个fake device它有一个虚假的设备因为这个device它只是一个文件它什么都没有它是一个空的它是一个link然后我们会当agent发现了有这个fake device的时候它会把实际的物理设备去做一个link到虚假的设备上于是就达成了因为这个agent它是知道要把哪一个卡对应到哪一个GPU banding上的所以它能够确切地知道我要把这台机器上的第0号卡分给哪一个泡的于是在pre-start的阶段就完成了这个链接的映射这样的话在泡的当中就可以找到实际的设备了对然后时间不多然后简单讲一下那个再讲一下一个就是就是如何加速那个数据加载的这样一件事情因为正常的一个比较理想的一个流程里面数据是从磁盘到内存再到GPU的显存然后GPU去进行计算拿回结果然后当然在从GPU在显存中做计算的时候这个时候下一步的由磁盘到内存的这个过程应该已经开始了但是实际的时候我通常达不到这样的一个效果因为有的时候一个数据级可能有几T甚至更大几十个T所以我们去露的数据的时候就有一大堆有一些就是有一个非常长的一个缓冲时间我们就可以将数据预先的加载到本地的磁盘当中因为我们在一个分布式集权里面如果我们要过分的依赖于一个分布式存储会给我们的分布式存储带来很大的压力如果我们想几十个T的训练数据都从分布式存储上读无论是效果或者是性能都会比较差所以我们会把数据先从分布式存储上面预先的加载到每一台机器上面然后让这个泡的去读这个数据的时候实际上是从本地读的而不是从它认为的远端存储上读当然这个数据也是一块一块加载的以适应我们说的整个数据的这样的一个流程然后这个地方可以同样就是帮助我们缓解对于分布式文件系统的这样的一个压力同时磁盘iOPS会明显的好一点然后以及说因为我们的数据级每次在每台机器上跑的训练可能是不一样的所以我们还会有一个类似于LRU这样的一个过程定期的把不用的数据然后这个数据块从这台机器上移走然后以换取本地的磁盘也不会暴涨后面这个可观的信息其实我们这次分享的比较简单只是涉及到就说你其实你在可观性这块你可以有很多工具去用但是在CoopLight这边其实它只提供了一个非常简单的一个日志就是说你的跑的STAR UP Duration然后里面会提到你哪个跑的然后它在Create Time Step和它的Polling的一些Time Step和Finish Polling的Time Step以及它看到它Running的一个时间所以其实目前的这个还是比较简单的但是也能够给你一个概念就是说你的跑的启动的几个时间点重要的时间点这个是在1.26加进去的然后最后一个就是说它的Matrix它会你能看到它的启动的一个直方图然后你可以看到这里这个15秒其实是有点慢的就是其实这个概念就是说启动时间在30秒到45秒之间的有一个就是15-14这样子就相当于有一个还是启动15秒还是比较慢的这时候你通过这个的话能大概定位出你机群里面是不是存在有些跑的它启动比较慢但是目前这个还比较简单如果有什么需求的话其实希望大家能够到社区去提一些feature request然后来加强这一部分的一个东西好 谢谢大家然后总体来说的话我们总共就是在介绍的是整个启动流程然后和一些tip就是你提示你哪些地方可能你要需要注意当然最后你自己的跑的启动速度慢可以通过这些方法来去定位到最终的解决方法可能还是需要一些进一步的工作的就包括刚才提到的这种AI方向的其实他们还是做了很多工作才能够让他的启动速度能加快那么一点点对 谢谢大家有什么问题吗没有的话大家再见谢谢大家