5k專案是飛天平台的里程碑，系統在規模、效能和容錯方面都得到了飛躍式的發展，達到世界領先水平。伏羲作為飛天平台的分布式排程系統，能支援單集群5000節點，併發執行10000作業，30分鐘完成100tb資料terasort，效能是當時yahoo ! 在sort benchmark上世界紀錄的兩倍。
在5k專案攻堅過程中，我們看到大型雲計算平台從設計到實現每一步都可能存在效能「陷阱」，原因主要在三個方面：規模放大效應，當系統擴充套件到數千節點時，原本非瓶頸與規模成正比的環節，其影響會被放大；木桶效應，很多時候，系統中99 % 的地方都被優化過，完成剩下1 % 的優化看起來也只是「錦上添花」，然而那1 % 很可能就會成為影響系統效能的致命的瓶頸；長路徑模組依賴，有些請求處理過程可能需要跨越多個模組（包括外部模組），而外部模組效能的不穩定性最終可能會影響到這個請求的處理效能和穩定性。5k專案是一場全方位戰役，給伏羲系統帶來規模、效能、穩定、運維等多方面的技術挑戰，例如下面的效能「陷阱」:
我們做了大量伏羲優化工作來規避上述的效能「陷阱」，涉及到架構設計、實現細節和模組依賴，透過現象看本質，從最底層效能分析入手一步步找到瓶頸。下面結合具體的實戰例子來分享優化過程。
通訊效能優化
訊息從到達伏羲master程序到最終被處理返回的總時間主要包括在佇列中等待時間和實際處理的時間，因此延時高無非是兩個原因：訊息處理本身的ops下降；訊息堆積在待處理佇列中未被及時處理。順著這一思路，在通過profiling發現伏羲master資源排程關鍵函式並沒有佔到整個訊息處理延時的大部分後，罪魁禍首就只剩下訊息堆積了。在繪出了伏羲master中資源排程訊息佇列中訊息堆積的曲線之後，果然發現當作業數量增加時，堆積的請求數量劇增（如圖2所示），每一條請求的處理時間也較小規模時高出很多。
定位到訊息堆積的問題後，我們立即對訊息通訊策略進行了流控，演算法簡單有效：傳送端檢查如果上次詢問的請求結果已經返回，表明目前伏羲master請求處理較為順暢，則間隔乙個較短的時間後進行下一次詢問。反之，如果上次詢問的請求超時，說明伏羲master較忙（例如有任務釋放大批資源待處理等），傳送端則等待較長時間後再傳送請求。通過這種自適應流控的通訊策略調整，伏羲master訊息堆積問題得到了有效解決。
關鍵函式優化
在5k專案中我們還重點關注系統中的關鍵函式效能，那裡也可能藏著「陷阱」。伏羲master在排程資源時的乙個關鍵操作是：比較乙個節點的空閒資源能否滿足該節點上排隊等待的所有資源請求，從而決定該資源分配給哪個任務。這個函式的呼叫次數會與機器規模和請求數量成正比，因此其速度對伏羲master的排程ops有決定性影響。
伏羲在排程資源時支援多個維度，如記憶體、cpu、網路、磁碟等，所有的資源和請求都用乙個多維的鍵值對表示，例如 。因此，判斷乙個空閒資源能否滿足乙個資源請求的問題可以簡單地抽象成多維向量的比較問題，例如r: [r1, r2, r3, r4] > q: [q1, q2, q3, q4]，其中1、2、3、4等數字表示各個維度，當且僅當r各個維度均大於q時才判斷r > q。比較次數決定了這個操作的時間複雜度。最好情況下只需比較1次即可得出結果，如判斷 [1, 10, 10, 10]大於 [2, 1, 1, 1]失敗；最差需要d次（d為維度數），如判斷 [10, 10, 10, 1]大於 [1, 1, 1, 10]需比較4次。在資源排程高頻發生時，必須對這裡的比較進行優化。
我們通過profiling分析了系統執行時資源空閒與請求情況，在資源充足時通常值最大的維度最難滿足，因此在資源排程場景我們採用基於主鍵的優化演算法：對每個資源請求的最大值所在維度定義為該向量的主鍵，當有空閒資源時首先比較主鍵維度是否滿足請求，如果在主鍵上滿足再比較其他維度。此外，對乙個節點上排隊等待所有請求的主鍵值再求乙個最小值，空閒資源如果小於該最小值則無需再比較其他請求。通過主鍵演算法，我們大大減少了資源排程時向量比較次數，伏羲master一次排程時間優化到幾個毫秒。注意到資源請求提交後不會改變，因此計算主鍵的系統開銷可以忽略不計。
伏羲master關鍵排程效能的優化增強了系統的規模擴充套件能力，使用者利用飛天平台能管理更大規模的集群，容納更多的計算任務，發揮出雲計算平台的成本優勢。
模組依賴性能優化
伏羲master支援故障恢復，在重啟後進行故障恢復時需要從nuwa讀取所有任務的描述檔案（checkpoint）以繼續執行使用者任務。考慮到之前nuwa服務在伺服器端對檔案內容沒有做持久化，伏羲master在讀取了checkpoint後還會再寫一次nuwa，這個回寫操作效能依賴於nuwa模組。在5000節點的集群上，名字解析壓力的顯著增加導致nuwa在server的回寫操作上也出現了效能下降問題，最終通過模組依賴傳遞到了伏羲master，從而影響了故障恢復的效能。經測試觀察，一次checkpoint回寫就消耗70秒，這大大降低了伏羲系統的可用性。
我們對伏羲master故障恢復進行了優化。首先，從伏羲master的角度，在故障恢復時剛剛讀取的checkpoint內容在nuwa伺服器端是不會發生改變的，因此讀取checkpoint後沒有必要回寫到伺服器端，只需要通知本地的nuwa agent讓其**即可，agent會負責伺服器宕機重啟時向伺服器推送本地快取的檔案內容。於是與nuwa團隊的同學合作，在nuwa api中新增加乙個只寫本地的介面，這樣伏羲master規避了在故障恢復時回寫checkpoint的效能風險。優化後，在5000節點集群和併發5000任務的測試規模下，一次故障恢復中處理checkpoint操作僅需18秒（主要時間在一次讀取）。可見在分布式系統中，對外部模組的依賴哪怕只是乙個rpc請求也可能是「效能陷阱」，在設計和實現時盡量避免出現在關鍵路徑上。
故障恢復是分布式系統保證可用性必須具備的功能，經過優化，伏羲master的快速故障恢復增強了飛天計算平台的可用性和穩定性，遮蔽了硬體故障，使使用者的使用過程不受影響。
工程經驗
高質量**沒有捷徑可走，也不能只靠制度流程，唯有認真二字：作者認真、reviewer認真、測試認真。
以上和大家分享了5k專案的一些實踐經驗，伏羲系統在5k專案中還做了很多有意義的系統優化和技術探索，參與其中收穫頗豐。效能是功能的一部分，是系統生死線而非錦上花。5k專案只是阿里雲計算平台技術發展的乙個開始，未來會在更大規模和更豐富計算模型等方面進一步發展，為使用者構築可用可靠的雲計算引擎，進一步降低成本，挖掘資料價值。
Centos 7 5節點 MPI集群配置
主機名 ip 記憶體 ios 硬碟 cpu核數 hw master 10.2.152.230 512g centos 7.5 2 6t 64hw node01 10.2.152.231 512g centos 7.5 2 6t 64hw node02 10.2.152.232 512g centos...
Redis單機6節點集群模式安裝
wget1.2 安裝gccyum install gcc c 1.3 解壓redistar zxvf redis 4.0.2.tar.gz1.4 編譯cd redis 4.0.2 make1.5 修改配置檔案 bind 0.0.0.0 daemonize no daemonize yes 1.6 啟...
Elasticsearch集群某一節點分片數為0
接手公司乙個elasticsearch集群，平時使用沒啥問題，今天檢視自己配置的索引生命週期是否正確，通過kibana發現某一節點的分片數為0，如圖 從圖中可以看出最後乙個節點分片數為0，也就是集群中有乙個節點一直沒有寫入資料 所以，我開啟了elasticsearch head直觀的看一下，如圖 其...