地球科學大規模并行應用的重疊存儲優化

陳璟錕 杜云飛

(國家超級計算廣州中心(中山大學) 廣州 510006)

對提升大規模并行計算規模與效率的研究和優化通常集中在算法的設計和優化上，比如在地球科學類程序中，通過特別的網格劃分以更好地實現負載均衡和壓縮通信的研究仍然長盛不衰[1].然而各種算法的加速比測試往往略去了I/O的占用時間，比如設置了超過計算時間的輸出間隔、關閉結尾輸出等.但在實際應用中，研究者通常需要獲得一個可以描述連續變化的過程而非一個最終狀態結果.這就要求模式在迭代計算過程中定期輸出中間狀態、輸入邊界數據進行同化以提高結果準確性和輸出數個檢查點以應對長時間運行可能碰到的硬件故障.所以，地球科學類軟件很早就被意識到是一種I/O敏感型的應用[2].

地球科學研究者往往缺乏足夠的時間和意愿去系統地學習與研究大規模并行程序的編寫，他們更愿意把主要精力放在對科學問題的研究上.因此地球科學模擬軟件最常見的輸出方式是簡單地將信息收集到根進程，由根進程整理并完成串行輸出.然而這種輸出方式會極大地限制程序在大規模計算時的性能表現.因為I/O時間不會隨著進程數的增加而下降，所以I/O時間占總時間的比例會越來越高，最終嚴重地削弱了峰值性能.在一些算例中，甚至會出現I/O時間遠超計算時間的情況.這除了讓科研工作者浪費時間和金錢外，更大的負面影響是在精細化數值預報領域，不但降低了數值預報的時效性，還增加了對硬件資源的需求并且提高了維護工作的難度.

在過去的數10年中，計算機科學家為了克服地球物理科學模擬的存儲墻問題進行多種研究，最終形成的主流共識是：1)由并行I/O取代串行I/O；2)將I/O和計算重疊[2]；3)優化必須是通用且輕量級的.因為計算進程的數據保存順序和文件存儲順序不同，所以需要建立一個緩存機制將每個進程的數據進行重新排列后再做并行輸出，由此誕生了收集式I/O的思路[3].收集式I/O的具體實現還能細分為采用本地硬盤作為緩存[4]和設立I/O結點作為緩存2種[5].這些思路還繼續發展并影響到新一代超級計算機的并行文件系統設計[6].為了讓收集式I/O發揮出這種并行文件系統的性能，計算科學家又在并行讀寫(MPI-IO)的基礎上根據I/O結點的具體硬件架構進一步開發了更高級的并行I/O庫[7-10]，比如輕便的收集式并行I/O庫ROMIO[7].因為收集式I/O的全過程可再分為通信收集和并行讀寫2部分，所以后續又有許多工作分別針對收集過程[11-12]和如何隱藏讀寫過程[13-15].

上述研究基本圍繞著底層硬件和基礎庫，這給程序的移植帶來了方便.但在實際的應用當中，地球科學軟件往往會采用以常用科學數據格式存儲數據，比如NetCDF(network common data form)，HDF5(hierarchical data format 5)等.這些文件格式庫的數據收集性能在大規模計算下是無法保證的，而且缺乏異步輸出的能力.這使得存儲墻對現今的地球科學大規模計算的負面影響依然非常嚴重，極端條件下甚至會出現超過80%的墻鐘時間是在輸出的情況.雖然有相當多工作在努力地提升并行I/O的讀寫性能[16]，但單從底層對I/O進行優化依然不足以克服存儲墻問題，我們還需要對應用軟件的訪存行為做出優化.

本文就是從應用層出發，參考主-從架構[17]，通過設立I/O進程[18]、分離I/O過程和計算過程以實現對地球科學軟件的訪存優化.本文將按照3方面組織：1)如何從應用層面設計一個重疊存儲以適應在天河二號上進行大規模計算；2)將詳細闡述這種優化是如何提升WRF(weather research & forecasting mode)的I/O性能，并證明其有效性；3)將這種優化移植到ROMS_AGRIF(regional ocean modeling system_adaptative grid refinement in Fortran)和GRAPES(global/regional assimilation and PrEdiction system)，以證明它的普遍性.

1 重疊存儲優化地球科學軟件輸出

因為地球科學的性質，其模擬過程往往是首先讀入初始條件，然后進入迭代循環，每當抵達設定好的輸出時間時將進行一次中間狀態輸出，直到循環到達終止時間.這意味著輸出的開銷會遠大于輸入，因此，我們先將精力集中在輸出優化上.

現在我們面臨的情況是輸出所花費的時間是一步迭代的數倍甚至數10倍，但一般也不會超過一個輸出周期.因此，我們的想法是將輸出過程和迭代計算分離，并確保一個輸出間隔內完成輸出，就是讓輸出隱藏在計算中，實現輸出優化的目標.這樣我們就不需要去追求并行輸出的極限速度，優化難度會減輕許多.

為了達成這個目標，我們進一步細分整個思路：

1) 建立專用的I/O進程，以實現輸出和計算同時進行.

2) I/O進程通過收集通信gather收集數據.

3) 因為gather是堵塞型通信，所以會暴露通信.

4) 根據最小生成樹算法(minimum-spanning tree algorithm, MST)，需要建立多個I/O進程以減少gather通信的消耗.

5) 多個I/O進程之間使用并行I/O完成輸出.

6) 由思路4,5可知，多個I/O進程和計算進程如何分組要符合連續讀寫的原則.

7) I/O進程應該分布在不同物理結點.

8) 通過劃分新通信域從而實現不同功能進程的混合分組.

思路1是實現輸出和計算重疊的基礎，雖然MPI-IO提供有非堵塞讀寫(MPI_FILE_iread(iwrite)_at)等接口，但NetCDF和HDF5并沒有使用.我們采用的gather通信方式會暴露通信時間，但帶來的好處是減輕結點內存的壓力以及減少程序編寫的復雜性.又因為gather通信是MST算法，耗時正比于進程數的數量，所以需要設置多個I/O進程，每個I/O進程只負責收集部分計算進程的數據，以將通信開銷抑制到可以接受的程度.思路5是我們要讓每次輸出耗時一定要小于一個輸出間隔.雖然從理論上無法完備地證明任何情況下并行輸出就能滿足輸出耗時小于輸出間隔，但在實際的地球物理模擬中并不需要每一步迭代完畢后都要輸出.在絕大部分情況下輸出間隔的墻鐘時間的量級都在10～100 s，而相應的輸出量在1～20 GB.所以我們在此選擇并行輸出，既可以滿足現實應用中的絕大部分情況而且還留有相當富余的性能空間以應對未來的性能需求.為了發揮并行輸出的性能，就產生了思路6的要求.思路7是為了突破單結點的物理內存限制和通信帶寬限制.思路8是為了方便管理不同種類的進程和減少對核心算法的修改，只需要將計算進程歸入一個全新的通信域，并用其代替核心算法中原來的全局通信域(MPI_COMM_WORLD)就可完成修改.

從上述的修改流程中可以看到這種優化方法有4種好處：1)相當于在原來的程序上外接了一個功能包，不涉及修改核心算法的邏輯；2)對核心算法的修改只有通信域的名字，這使得我們可以在不明白模型和算法細節的情況下也能完成重疊存儲優化，這也是優化方法具有通用性的一個表現；3)在通信域劃分時已經考慮了后續并行輸出的速度問題，減少磁盤讀寫競爭問題；4)更加充分地利用了超級計算機的硬件，突破單結點帶來的網絡帶寬和內存瓶頸.

2 WRF的IO優化

WRF是目前國內與國際上最流行的中尺度天氣預報研究軟件之一，是典型的地球科學類軟件.WRF從3.0版本就開始考慮大規模計算下的輸出問題，它同樣通過提供設置額外I/O進程的方式實現優化.假設我們將I/O進程設為2，并為作業提供總計12個進程，而運行作業的超級計算機每個結點具有6個CPU核.那設置I/O進程前后的WRF進程分配如圖1(a)和圖1(b)，反映到具體的物理CPU核劃分如圖1(c).

圖1(a)(b)(d)中，每一列代表一個進程，圓形(黑色)箭頭代表迭代計算過程，菱形 (綠色)箭頭代表通信，長方形(紅色)代表輸出過程，虛線代表計算進程空閑；圖1(c)(e)中，深色(藍色)方塊代表一個計算進程，淺色(黃色)陰影方塊代表一個I/O進程，褐色線條圍成的區域代表通信域的劃分.圖1(a)沒有I/O進程，由根進程負責輸出2個結果文件；圖1(b)設置了2個I/O進程，但只有第2個文件的輸出與計算實現重疊；圖1(c)不同類型進程在12個CPU核上的分布和數據收集通信域的劃分；圖1(d)優化后的輸出流程；圖1(e)優化后不同類型進程在12個CPU核上的分布和新的數據收集通信域劃分.

圖1(a)展示了在沒有I/O進程時，根進程負責完成數據的收集并輸出結果，在整個收集-輸出的過程，其余進程除了發送數據的操作外都處于閑置狀態.圖1(b)表示設置了2個I/O進程后，每當進入預設的輸出時間點，計算進程都會將數據發送給I/O進程，隨后由I/O進程完成數據整理和并行輸出.每個I/O進程都只會接收到處于同一個通信域的計算進程的數據，數據收集通信域的劃分如圖1(c).對比圖1(a)和圖1(b)我們就能發現原設計的第1個問題.雖然在設置了通信進程后，最后1個文件的輸出時間和計算時間發生了重疊，對輸出時間占比有所改善，但除最后1個文件外，其他文件的輸出時間仍然暴露在外.WRF的文件輸出順序是第1層網格—第2層網格—第3層網格.通常研究者會將第3層網格設置得最為密集，其結果文件也是最大，輸出耗時最長.這使得原版的設計在部分情況下已經取得了比較明顯的效果.但該設計卻不適合2種情況：情況1是不同層網格的格點數相差不大，只是格點間代表的距離不同；情況2是研究者設置了輔助變量輸出，輸出順序變成先輸出1層網格的數據，再收集該層的輔助變量數據并另開1個新文件保存.情況2會使得只有最后1層的輔助變量文件成功被隱藏，而一般輔助數據文件都遠小于主要數據，是否隱藏意義不大.原設計的另1個問題是所有的I/O進程都安排在最后，如圖1(c)所示，這往往意味著I/O進程會放在同一個結點.雖然放在同一個結點對于收集式I/O是一種理想情況，但卻也有通信和內存這2個瓶頸.

Fig. 1 Cartoon of WRF’s workflow圖1 WRF的工作示意圖

針對這2個問題，我們首先選擇調整I/O進程的工作順序.每進入1次新的收集-輸出時間點，I/O進程先全部接收本次輸出的所有數據，然后才開始逐一整理并輸出到硬盤.如此調整后，除最后1次輸出外，其余時間點的輸出將全部實現隱藏，只剩余收集通信暴露在外，如圖1(d)所示.

為了抑制收集通信gather的耗時，根據MST算法的特點，我們一是可以增加更多的I/O進程以減少每個I/O進程負責的計算進程數，二是可以將I/O進程分布在各個不同的結點以變相提高通信帶寬.為此，我們引入1個可由使用者設定的分布值，可主動控制I/O進程的分布程度.如果設置為1，則如同原設計一般讓所有I/O進程排列在最后；如果設置為2，則意味著12個進程被分為2組，每組最后的2/2=1個進程為I/O進程，效果如圖1(e)，成功利用了2個結點的通信帶寬.

自古嫦娥愛少年，這個騷貨沒準看上你啦，想讓你做鴨子哩，她一天到晚就是一個人晃蕩，沒見過她老公，這熊事，她還不知道是個啥人哩。這樣的女人，看她那嘴，像剛喝過雞血似的鬼，咱可不能招惹，她男人萬一是個道上的，要殺你剮你，讓你缺胳膊少腿，可甭怨我這個叔沒給你打預防針。

3 WRF算例測試結果

我們使用超級計算機天河二號作為性能測試平臺，它具有17 920個計算結點，每個結點的配置為2路24 CPU核，單核頻率2.2 GHz，4路64 GB內存，自主研發的高速互聯具有點點帶寬140 Gbps，采用層次式Lustre文件系統，在存儲服務器(OSS)和計算結點間還有1層配備了固態硬盤(SSD)的I/O結點用于加速存儲性能.

我們選用的WRF測試算例為模擬全中國2015-07-27T12:00:00—2015-07-30T12:00:00共72小時的天氣變化，每90 s為1個模擬步.3層嵌套網格：220×180×45，481×391×45，1 216×895×45，每層網格的相鄰格點間距分別為45 000 m，15 000 m，5 000 m.每層網格的輸出間隔均為1 h，采用PNetCDF庫并行輸出NetCDF格式文件，沒有輔助變量輸出，條帶數設置為4.我們使用的WRF版本為3.6.1，但其關于輸出的代碼與3.7.1相同，與3.8.1和3.9相似.我們的編譯器為Intel-14，WRF模式選擇em_real，只允許根進程輸出日志信息.

Fig. 2 Performance of WRF after output optimization圖2 輸出優化后的WRF性能圖

我們選擇3種設定以對比優化效果，分別是：原版無I/O進程、原版帶2個I/O進程、優化版帶2個I/O進程并且分布值為2.第1種設定的輸出方式為NetCDF，而后兩者均為PNetCDF.我們的測試結果如圖2所示.每一組柱狀圖從左起按順序分別代表第1，2，3種設定方案.橫坐標代表計算進程數，所以每一組柱狀圖的第2和第3條使用的總進程數實為計算進程數加2.從圖2可以看到隨著進程數的增加，輸出占總時間的比會越來越高，即使在超過了性能峰值后仍具有這種情況.原版程序在設置了I/O進程后，在3072進程時的性能提升了約19.8%，但還是能明顯看到輸出時間.在對輸出做了優化后，峰值性能再次獲得約11.4%的提升，相比無I/O進程時則是提升了約33.5%.這證明了我們的輸出優化是有效且可行，達到了預想的效果.

我們還能從圖2看到，隨著進程數的增加，暴露的收集通信時間也在增長，尤其是從進程3 072提升到6 144時最為明顯.我們進一步測試在不同I/O進程數和不同分布值下收集通信時間的變化情況，并將結果整理成表1.

Table 1 Effect of Output Tasks and Splits表1 IO進程數和分布值的影響

Table 1 Effect of Output Tasks and Splits表1 IO進程數和分布值的影響

ComputationTasksI∕OTasksDistributionValueCommunicationTime∕s6144219036144228666144101646144102396144105416144101039

從表1我們可以看到，在相同分布值下10個I/O進程的通信開銷遠低于2個，主要原因就是gather通信開銷和進程數直接相關.增加I/O進程數意味著每個I/O進程負擔的計算進程數變少，自然gather通信開銷也會相應地減小.在同I/O進程數不同分布值下，通信開銷也會有一定的下降，這表明我們的修改確實更有效地利用了帶寬.但因為本例子的通信量并不大，所以還是進程數數量導致的開銷占據主導.

我們為完成圖1和表1的測試，選擇了在計算進程保持一致的基礎上設置額外I/O進程.這樣可以保證計算的穩定性，但也帶來總進程數不一致的問題.由此，我們還可以引出另外1個問題：總進程數一致的情況下，如何分配I/O進程和計算進程是最優解?

在討論這個問題前，我們有必要先解釋為什么會選擇固定計算進程數的做法.這是因為WRF的負載均衡策略是將計算進程數分解為2個盡可能相近的因數，并利用它們完成xy平面的劃分.但如果這2個因數相差較大時，這個簡單的負載均衡策略就會極容易引起程序崩潰.假設現在從6 144個進程數中劃分出10個I/O進程，那6 134只能被分解為2×3 067，進而導致作業崩潰.所以當總進程數一定時，I/O進程數的設置還必須考慮負載均衡策略，不能只考慮通信開銷和計算時間之間的競爭.在此基礎上，我們做出表2.

從表2可得，計算與I/O進程的數量比在1 000∶1至500∶1間能取得最優效果.我們認為這是天河二號硬件性能參數下的特解，不同系統應該會有不同的結果.

Table 2 Performance of Different IO Processes NumbersUnder Constant Total Processes Number

表2 總進程數不變下不同IO進程數的表現

Table 2 Performance of Different IO Processes NumbersUnder Constant Total Processes Number

ComputationTasksI∕OTasksComputationTime∕sCommunicationTime∕s6141312067.2346.466138612038.490.5761321212161.140.376120241224027.28

4 對同類軟件的優化

4.1 ROMS_AGRIF

ROMS是國際上知名的海洋模擬軟件，它具有多個分支.其中的1個分支ROMS_AGRIF由法國研究小組開發，加入了多個生物化學模塊，側重于模擬研究海洋與生物之間的關系.因為開發者認為應該盡可能地避開通信引起的消耗，所以其輸出過程被設計為每個進程按順序逐一將其保有的數據串行輸出到同一個NetCDF文件.

這種設計雖然避開了輸出導致的通信消耗,但在大規模計算下多個進程逐一打開關閉同一個文件，逐一輸出不連續數據所耗費的時間也同樣可觀，在現代超級計算機硬件性能下不再是1個合理的交換.按第1節所述的方式，我們優化了ROMS_AGRIF的輸出設計.收集過程分為3步：1)通過gather將各計算進程需要傳輸的數據量大小傳送給I/O進程；2)I/O進程通過接收到的信息計算出接收內存的大小；3)用gather完成該變量的數據收集.等所有變量的數據都收集完畢后，I/O進程按順序整理并采用并行庫PNetCDF完成并行輸出.

我們選擇的算例為南中國海單層網格，網格大小為1 200×1 310×60，模擬129 600步，每720步輸出3個文件，每個文件的每次輸出量約在1.5 GB，條帶數設置為4.

測試結果如圖3所示，我們在前48，96，192個計算進程時僅比較了原版和存在2個I/O進程時的情況，從384計算進程開始加入對比24個I/O進程的情況.在48和96計算進程時， 2個額外I/O進程不僅抑制了輸出時間，連帶計算速度也出現了加快的情況.這是因為ROMS對內存很敏感，在加入2個I/O進程后，我們必須提交3個結點才能滿足所需的CPU核數.依照天河二號的作業管理系統設定，這種提交方式會導致50個進程被3個結點平分.這意味著減少了內存帶寬的競爭，因此出現計算速度加快的現象.這種對內存敏感的情況也體現在384進程前獲得了超線性加速比.

Fig. 3 Performance of ROMS_AGRIF after output optimization圖3 輸出優化后的ROMS_AGRIF性能圖

圖3還展示了與計算規模相匹配的I/O進程有利于控制收集通信的開銷.在3 072進程時，24個I/O進程可以有效保證輸出所占時間不到總時間的5%，充分釋放出原作者對通信優化后的計算性能.

4.2 GRAPES

GRAPES是我國自主開發的天氣預報程序，在天河二號上已經實現1 km模式的業務化運行，是目前國內網絡精度的最高水平.1 km模式需要每12 min啟動1次.經過存儲優化后的1 km模式，墻鐘時間從26 min縮短至9 min，減少了對硬件資源的需求，減輕了運維壓力，也提升了1 km預報業務的穩定性.

鑒于GRAPES的版本眾多，我們以廣州熱帶所提供的GRAPES業務版本為例開展GRAPES的I/O優化.原版GRAPES的I/O過程為：所有進程通過發送命令MPI_send將數據發送到根進程，而根進程先使用多個接收命令MPI_recv完成通信后開始進行數據整理并串行輸出Fortran非格式化文件.

在實際測試中發現，GRAPES的輸出所占時間比會隨著進程數量的增加而急速上升.這是因為頻繁的啟動發送和接收命令消耗了大量的時間.我們對GRAPES的收集通信優化手段與ROMS_AGRIF類似，避免了因為頻繁啟動通信命令而引起的巨額開銷.

GRAPES的輸出文件采用Fortran非格式化文件格式，與MPI-IO的格式并不完全一致.為了方便后處理程序，我們編寫的并行輸出過程也仿照了該格式，雖然會對讀寫速度帶來負面影響，但輸出耗時依然遠小于1個輸出周期，不會對總時間帶來顯著影響.

從負載均衡的考慮出發，幾乎所有地球科學模擬軟件的負載均衡策略都是按照進程數將xy平面劃分為大小相近的區域，而z方向不做劃分，GRAPES也是如此.因為算法上的要求，GRAPES的變量數組存儲按照的是xzy順序，這意味著當存在多個I/O進程時，I/O進程只能在x或y方向中選取1個保證該方向的數據連續性.因為GRAPES結果文件內的數據是按照xyz順序排列，所以在多個I/O進程并行輸出同一個變量的同一個xy平面時必然會引起磁盤資源的爭搶，最終拖慢輸出表現.考慮到在日常的業務化使用當中，GRAPES的每次輸出量均不超過1 GB的情況，我們暫時將所有的I/O進程放在同一個結點內，這樣做可以直接利用天河二號的層次式存儲加速輸出速度，避開磁盤資源發生爭搶的情況.我們會在將來采取更成熟的收集式I/O，比如ROMIO，以嘗試解決這個問題.

對GRAPES的測試結果如圖4所示，可見在設置了24個I/O進程時，在3072進程時依然取得了相當好的加速效果.在實際的業務預報應用中規模已經達到了5300核，而其I/O時間依然可以忽略不計.

Fig. 4 Performance of GRAPES after output optimization圖4 輸出優化后的GRAPES性能圖

5 總 結

因為硬件上的原因，存儲的速度遠落后于計算的速度，這使得存儲問題一直是大規模算法能否實用化的主要挑戰之一.地球科學領域內常用的軟件幾乎都會碰到這個問題，并且隨著規模的擴大，這個問題會越發嚴重.存儲的解決方式和硬件架構有關，因此我們針對天河二號的架構，設計了一套應用級別的重疊存儲優化，希望解決大規模計算時的存儲問題.

這套重疊存儲優化的核心思路是：

1) 建立專用I/O進程；

2) 設置多個I/O進程以抑制通信開銷，變相增加內存容量和通信帶寬；

3) I/O進程收集完所有文件的數據后再輸出；

4) I/O進程之間采用并行輸出.

雖然部分應用軟件，比如WRF已經有了這方面的探索，但要么不完善，要么不適應天河二號的存儲架構，所以都無法發揮出天河二號的存儲性能.

本文對WRF，ROMS_AGRIF，GRAPES做出適合天河二號架構的存儲優化，均獲得了預期中的良好效果.測試表明：經過優化后的WRF峰值性能相比原版有了近11.4%的提升，ROMS_AGRIF的峰值性能提升936%，GRAPES的峰值性能提升140%.因為都不涉及物理模型，優化后的計算結果在有效精度內與原版程序保持一致，這驗證了重疊存儲優化的正確性和有效性，也證明了該優化思路能普遍應用于天河二號上的地球科學類軟件.我們對存儲的優化也進一步提升了天河二號在華南地區高精度天氣預報業務和南中國海預報業務中的作用.

致謝我們在此感謝國家超級計算廣州中心盧宇彤主任的支持，感謝國家超級計算廣州中心高性能部門的同事對研究內容的有益討論和指導，感謝國家超級計算廣州中心系統部同事對測試所需的硬件和計算資源提供的技術支持.