831      阿裏雲  技術社區[雲棲]

門道多：一次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任務不要花時間去攢資源（資源要充足），但同時集群利用率又要保障，現在也在探索一些解決方案，希望大家也多多提提想法。總之，優化這條路還長著呢

最後更新：2017-06-05 11:33:45

  上一篇：  velocity的html語義轉換

  下一篇：  Android優化係列一： 日誌清理