地球科學大規(guī)模并行應用的重疊存儲優(yōu)化

陳璟錕 杜云飛

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

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

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

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

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

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

1 重疊存儲優(yōu)化地球科學軟件輸出

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

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

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

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

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

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

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

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

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

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

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

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

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

2 WRF的IO優(yōu)化

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

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

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

為了抑制收集通信gather的耗時，根據(jù)MST算法的特點，我們一是可以增加更多的I/O進程以減少每個I/O進程負責的計算進程數(shù)，二是可以將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內存，自主研發(fā)的高速互聯(lián)具有點點帶寬140 Gbps，采用層次式Lustre文件系統(tǒng)，在存儲服務器(OSS)和計算結點間還有1層配備了固態(tài)硬盤(SSD)的I/O結點用于加速存儲性能.

我們選用的WRF測試算例為模擬全中國2015-07-27T12:00:00—2015-07-30T12:00:00共72小時的天氣變化，每90 s為1個模擬步.3層嵌套網(wǎng)格：220×180×45，481×391×45，1 216×895×45，每層網(wǎng)格的相鄰格點間距分別為45 000 m，15 000 m，5 000 m.每層網(wǎng)格的輸出間隔均為1 h，采用PNetCDF庫并行輸出NetCDF格式文件，沒有輔助變量輸出，條帶數(shù)設置為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 輸出優(yōu)化后的WRF性能圖

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

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

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

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

ComputationTasksI∕OTasksDistributionValueCommunicationTime∕s6144219036144228666144101646144102396144105416144101039

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

我們?yōu)橥瓿蓤D1和表1的測試，選擇了在計算進程保持一致的基礎上設置額外I/O進程.這樣可以保證計算的穩(wěn)定性，但也帶來總進程數(shù)不一致的問題.由此，我們還可以引出另外1個問題：總進程數(shù)一致的情況下，如何分配I/O進程和計算進程是最優(yōu)解?

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

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

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

表2 總進程數(shù)不變下不同IO進程數(shù)的表現(xiàn)

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

ComputationTasksI∕OTasksComputationTime∕sCommunicationTime∕s6141312067.2346.466138612038.490.5761321212161.140.376120241224027.28

4 對同類軟件的優(yōu)化

4.1 ROMS_AGRIF

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

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

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

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

Fig. 3 Performance of ROMS_AGRIF after output optimization圖3 輸出優(yōu)化后的ROMS_AGRIF性能圖

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

4.2 GRAPES

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

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

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

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

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

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

Fig. 4 Performance of GRAPES after output optimization圖4 輸出優(yōu)化后的GRAPES性能圖

5 總 結

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

這套重疊存儲優(yōu)化的核心思路是：

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

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

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

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

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

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

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