一 為什麼要分享一個問題排查過程
作為初級使用者來說隻要會基于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；
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 記憶體不是瓶頸)
task類型
執行個體數（total/ready/running）
單執行個體cpu需求
彙總cpu
coordinator
1/1/0
100
server
3000/2/2998
1500
4500000
worker
3000/0/3000
所有彙總
9000100
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,
"cpu": 1050, //worker打了7折
"memory": 5000}// mem不打折
ps内部沒有使用all-or-nothing，隻是他的行為符合aon特征；
這樣一來，上述表格需要調整一下
1500*0.5
2250000
1500*0.7
3150000
5400100
這回資源對上了，單機起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任務，其配置如下：
"resource":{"cpu":1200,"memory":50000}，
"managedinstancenum":240，
如按s10機型來看，基本就是占了120台機器，每台機器還剩下700（7core），剛剛不夠這人ps任務的server用（需要750）。如果按n41機型來看，單機還能剩下6300-2400=3900，是以是夠起server的，這裡基本可以判斷出該xlibmpi任務占了約90台s10，30來台n41。
20~22點：這期間資源是夠的，按理說任務應該能跑起來了，但使用者回報沒有看到任務有過運作過的日志記錄， 2小時肯定夠任務跑好多輪了。
22~01（被kill）：這期間大批量機器被加黑，如下圖所示，通過背景日志分析發現共有32台被加黑了。同時上圖alimm_mpi_k2在22點左右的空降也說明那個時間機器加黑數較大，同時影響了兩個quota組，而alimm_mpi_kgb隻被影響了幾台，這個時候總的實體上可用機器數應該就定格在2998台了，直到被kill也沒有拿夠。
【第五輪】coordinator也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；
機器加黑時有發生，而且有時候量還會比較大，如果幾十台；可以通過神農監控檢視；
1、會發現像這回這種大任務資源需求大，設定好plan mem/cpu實際上較難，受實體部署/單機網卡/單機記憶體和cpu/是否統一機型等多種因素影響，需要測試出一些經驗值；
2、logview裡面coordinator failover之後看不到之前的stderr了
3、之前想做的aon/mpi類任務按團隊隔離還是會面臨實體上互相影響的情況，面臨多因素難平衡的問題，一方面希望worker/server 盡量分散（要求機器多），另一方面又需要aon任務不要花時間去攢資源（資源要充足），但同時叢集使用率又要保障，現在也在探索一些解決方案，希望大家也多多提提想法。總之，優化這條路還長着呢