门道多：一次MaxCompute PS任务的问题排查之旅

关于PS是什么，可以参考一下以下两个介绍：基于参数服务器的大规模在线学习算法和Parameter Server。更多问题可以咨询玄乐。下面主要总结一下这回遇到一个PS任务跑不起来的问题排查过程。不想看过程的直接看最后一点总结就行。

一 为什么要分享一个问题排查过程   

    作为初级用户来说只要会基于SDK的编程和命令使用就OK了，但对于广告这种重度高级用户来说，如果还把计算框架和MaxCompute当成黑盒来用，任务跑不起来了或者任务出错了就只能两眼一抹黑了，这次分享一来是By Case解了一个很复杂的问题，二来是摸清了里面的门道，简单是一环扣一环，觉得有必要分享一下，给有需要的同学可做下参考。

二 问题的现象

    一个PS任务从提交到最后人工Kill经过了7小时，一直没起起来，而该任务以前是可以正常运行完成的。如下图所示，有两个实例一直处在Ready状态。

三、排查过程
    首先，在排查之前有必要交待一些基本信息，PS任务主要角色三个：coordinator/server/worker，如下盗图，

这里面有几个关键点先交待下：

1、coordinator占用资源较少，只会起一个Instance，占用资源基本是1Core + 1G；

2、Server和Worker占用资源较多，根据特征量和样本大小的不同其实例个数也有较大差别，目前大的能到3000个实例（如本Case），每个实例需要10Core + 5~20G；

3、aon：即all-or-nothing，介绍，必须（三个Task）所有的实例都分配到了资源才会开始进行迭代计算；aon模式是采用机器打标预留资源的方式给任务分配资源，会以占满整机的方式分配，照例来个示例：一个任务有120个实例，每个实例要8core，单机是31Core，那么一台机器上就能放3个实例占24Core，剩下7Core则分给其他任务，该任务一共要占120/3=40台机器。

4、中间如果某个实例失败了，整个计算都会暂停，直到所有实例拿够资源才会恢复运行；

5、如下出现数字中如果没有单位，则CPU单位为1核=100个基本单位、内存单位为MB；

【第一轮】：目标直指资源不够。

任务所在的AY87B集群资源：按s10机型(32Core + 128G，实际可用31Core + 110G)推算应该是3600+的机器数，目前分给了两个quota组，alimm_mpi_kgb：2000台，alimm_mpi_k2：1100台（感觉绰绰有余的样子）；

该Job被Kill时的基本信息：(为了简化，略去mem信息，因为本Case 内存不是瓶颈)

PS是在aon模式下工作的（这个判断后面被证实是不完全对的，汗），单机能分配的worker是2个(15 * 2=30core，31core能容下两个)，Server单机也是能起2个，这样算下来基本需要3000台机器；

咦，但Job所在的quota组（alimm_mpi_kgb）只分配到了2000台，按理说应该有1000台的缺口会导致有2000个实例处在Ready状态，同时算出来的资源需求是9000100，而神农监控里面发现实际资源需求(request项)只有5400100，如下图

问题出在哪？

         【第二轮】：PS内部有玄机

         找到玄乐细细了解了一下，得到两个很重要的线索，PS内部有一些默认约束：

• 由于某种原因，Worker的资源申请量会打7折，Server会打5折；
• 单台机器上只能启动1个Server和2个Worker；如下是发给Fuxi的json串

 "PSServerTask": {
                "MaxAssignCountEachMachine": 1,

 "Resource": {
                    "CPU": 750,// server打了5折
                    "Memory": 5000} // mem不打折

}

"PSWorkerTask": {

                "MaxAssignCountEachMachine": 2,

 "Resource": {
                    "CPU": 1050, //worker打了7折
                    "Memory": 5000}// mem不打折

}

• PS内部没有使用all-or-nothing，只是他的行为符合aon特征；

这样一来，上述表格需要调整一下

这回资源对上了，单机起2个worker需要1500台机器（能同时起1500个Server），起3000 个server还需要1500台，缺口只有2个Server（2台），但集群明明逻辑上有3600+，为什么持续7个小时分配不到，而集群的整体利用率也不是很高，如下图：

【第三轮】这时你必须知道的物理部署情况

         由于一直负责广告的MaxCompute接口，所以马上想到了ay87b集群物理上机器型号有差异，是s10(32core + 128G)和n41（64core + 192G，实际可用63core + 170g）混布的，物理上大概有3040台，这个数字和3000好接近呀，但还是大于3000呀，同时这个时候发现了另外一个现象：虽然最终发现有2个Ready的Server，但实际这7个小时经历了三段：18~20点缺口有53台；20~22点资源是够的；22点到被Kill资源最终差2台；

【第四轮】机器有加黑、资源有碎片

是不是有什么情况导致机器可用数低于3000呀，现在一切应该朝着可用数2998去追踪了。

18~20点：从资源缺口和实际的server实例的start_time算出有53台【（request-used）/(1500 * 0.5)】的机器缺口，基本确定有两个因素：一是华佗加黑了几台机器，二是当时另外一个quota组（alimm_mpi_k2）启动的任务了多个aon类型的xlibmpi任务，有90台左右的机器上剩余资源小于750，导致资源碎片化，如下图中的蓝色部分，正好是8点有个资源使用的下降，说明有个任务跑完了释放出来了部分机器。

最终也找出了这个Xlibmpi任务，其配置如下：

20~22点：这期间资源是够的，按理说任务应该能跑起来了，但用户反馈没有看到任务有过运行过的日志记录， 2小时肯定够任务跑好多轮了。 

22~01（被Kill）：这期间大批量机器被加黑，如下图所示，通过后台日志分析发现共有32台被加黑了。同时上图alimm_mpi_k2在22点左右的空降也说明那个时间机器加黑数较大，同时影响了两个quota组，而alimm_mpi_kgb只被影响了几台，这个时候总的物理上可用机器数应该就定格在2998台了，直到被kill也没有拿够。

【第五轮】coordinator也failover了

         对于20~22点任务没执行这个问题实际上是个误判，因此通过玄乐提供的诊断任务工具（Here）发现coordinator在21:59:16发生过failover，如下图

，发生failover时之前的日志就被清空了，所以实际上该Job是运行过2小时左右的。这下整个问题基本也就梳理清楚了。

四 总结的几个收获点

• PS没有设置isAllOrNothing; Ps行为上是aon，但在资源分配上实际没有使用aon；
• 单机默认有2Worker 和1Server限制；
• Worker的CPU会打7折，Server的CPU会打5折，而Mem则不打折。至于原因嘛还是因为Fuxi底层在CPU限制上面没有太死，而Mem上则使用过了就会被Kill。
• 规划任务和资源时一定要留点Buffer；
• 分布式系统下物理部署有时候很难对用户透明；
• PS内部会对coordinator/server/worker做failover；
• PS默认10轮做一次checkpoint；
• 查看任务jobstatus和任务在控制集群上的行为可以参考两个工具：detect和 SLS
• 机器加黑时有发生，而且有时候量还会比较大，如果几十台；可以通过神农监控查看；

五、存在的问题

1、会发现像这回这种大任务资源需求大，设置好plan mem/cpu实际上较难，受物理部署/单机网卡/单机内存和cpu/是否统一机型等多种因素影响，需要测试出一些经验值；

2、Logview里面coordinator failover之后看不到之前的stderr了

3、之前想做的aon/mpi类任务按团队隔离还是会面临物理上相互影响的情况，面临多因素难平衡的问题，一方面希望worker/server 尽量分散（要求机器多），另一方面又需要aon任务不要花时间去攒资源（资源要充足），但同时集群利用率又要保障，现在也在探索一些解决方案，希望大家也多多提提想法。总之，优化这条路还长着呢