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