高性能計算問題通常具有子任務(wù)并行化的特點,同時在執(zhí)行過程中需要消耗大量計算資源。以虛擬機作為分布式節(jié)點的傳統(tǒng)云計算已經(jīng)被證明能夠很好地處理一些常見的高性能計算問題,但分布式環(huán)境的管理和解決方案的分布式設(shè)計令處理過程變得較為復(fù)雜。函數(shù)計算是一種新的無服務(wù)器云計算范型,其自動擴容的特性和可觀的計算資源恰好與高性能計算問題能夠很好地結(jié)合,但函數(shù)計算自動擴容的特性帶來的冷啟動延遲卻是函數(shù)計算平臺上一個無法避免的問題,尤其是在執(zhí)行高性能計算這一類存在高并發(fā)量作業(yè)的任務(wù)時,這種延遲會被進一步放大。首先分析一個高性能計算任務(wù)在冷啟動和熱啟動情況下的完成時間,同時分析造成額外延遲的原因,然后結(jié)合時間序列分析工具和平臺自身的擴容機制,提出一種預(yù)熱方法,這種方法能夠有效地降低高性能計算任務(wù)在函數(shù)計算平臺上產(chǎn)生的冷啟動延遲。 

【文章來源】：計算機工程與科學(xué). 2020,42(11)北大核心

【文章頁數(shù)】：8 頁

【部分圖文】：

函數(shù)計算平臺架構(gòu)圖

實驗結(jié)果如圖4所示,一次完整的預(yù)熱測試包括容器預(yù)熱和執(zhí)行計算任務(wù)2個過程。從圖4中可以看到,冷啟動情形下單次請求的執(zhí)行時長為7 300 ms,遠遠高出熱啟動情況下的執(zhí)行時長578 ms。而在本文提出的方法中,預(yù)熱時長大約為360 ms,執(zhí)行計算任務(wù)時長大約為4 500 ms。同冷啟動情形相比,利用阿里云平臺本身的快速擴容機制,預(yù)熱措施的確能夠有效地縮短冷啟動延遲。但是另一方面發(fā)現(xiàn),無論是冷啟動還是預(yù)熱之后的執(zhí)行時長,都遠遠高于熱啟動情形下的執(zhí)行耗時。發(fā)生這種現(xiàn)象的原因可能有2個:第1是因為counter和多個Computing Unit本身的冷啟動延遲效應(yīng),在容器啟動時存在一定的延遲;第2則是2種情形下的容器環(huán)境并沒有加載完全,而熱啟動的測試都是在冷啟動環(huán)境執(zhí)行多次后進行的測試。5 結(jié)束語

計算任務(wù)大小實驗結(jié)果如圖2所示。圖2a描述的是運行時長與內(nèi)存大小之間的關(guān)系,在該實驗中,計算量是保持一致的(即斐波那契數(shù)列的計算長度是一致的)。盡管當(dāng)內(nèi)存被設(shè)定為256 MB時,運行時長會處于最低,但仍然遠遠高于熱啟動的運行時長。如圖2a所示,在不同的內(nèi)存設(shè)定中,2種啟動模式下的平均運行時長分別為108 ms和13 ms,其差值大約為100 ms左右。圖2b展示了計算量大小與在不同啟動模式下的延遲關(guān)系,從中可以看到,盡管在冷啟動和熱啟動2種情況下,運行時長都會呈指數(shù)增長,但是二者的差值仍然保持在100 ms左右。這表明冷啟動延遲是一個趨于穩(wěn)定的值。最后在第3個實驗中觀察了FC本身采用的快速擴容機制。在計算斐波那契數(shù)列的實驗中,利用阿里云FC提供的SDK進行了并發(fā)請求的測試。每次測試中,在客戶端同時向同一個云函數(shù)發(fā)送10條執(zhí)行請求,并觀察其平均執(zhí)行時長。其中斐波那契數(shù)列的計算量設(shè)定為遞歸計算第35項,同時將云函數(shù)的最大允許使用內(nèi)存設(shè)定為512 MB。如表2所示,當(dāng)一個云函數(shù)存在1個容器實例時,意味著1個熱啟動處理和9個冷啟動處理,那么10條請求的平均處理時長并不會太長,僅僅比單次熱啟動延遲多17 ms;而當(dāng)不存在容器實例時,意味著10條請求都是冷啟動,此時平均處理時長不僅僅高于單次熱啟動時長,甚至比單次冷啟動時長還要高出將近30%。這個實驗結(jié)果說明,阿里云能夠利用一個已有的完整容器——阿里云容器團隊提出的DADI加速器[14]進行快速擴容。

【參考文獻】：
期刊論文
[1]基于無服務(wù)器架構(gòu)的邊緣AI計算平臺[J]. 劉暢,毋濤,徐雷.  信息通信技術(shù). 2018(05)
[2]高性能計算的發(fā)展現(xiàn)狀及趨勢[J]. 張軍華,臧勝濤,單聯(lián)瑜,石林光.  石油地球物理勘探. 2010(06)



本文編號：3028348