大數據任務執行時間優化案例分享,大數據技術下如何提高預處理能力

大數據任務執行時間優化案例分享

問題的背景

在項目中，大數據的任務執行時間較長，需要進行優化，使大數據的任務執行時間優化到客戶可以接受的時間。

分析兩個原因

業務場景分析

該場景中的大數據任務主要是對數據進行mapreduce操作，包括兩個子任務。第一個子任務的地圖數量(每張地圖大小為128M)約為4300張(這些地圖任務分散在不同的服務器上，泰山集群有6400+核處理，可以充分利用泰山的多核優勢)。地圖的執行時間是10分鐘。但reduce的數量固定為200(即最多200個內核并行處理reduce任務)，reduce的執行時間約為1小時30分鐘，耗時較長。同時reduce的數量少于map的數量，無法充分發揮泰山多核的優勢，第二個子任務也是reduce階段，耗時較長。

服務器基礎的性能分析

執行大數據任務時，cpu利用率不高，磁盤io和網卡IO不存在瓶頸。但是，網卡中斷需要綁定到內核，并且可以調整磁盤緩存參數來提高性能。

三種解決方案

3.1網卡調整

3.1.1中斷核結合

中斷關聯性被描述為一組能夠對特定中斷做出響應的CPU。如果應用程序可以通過關聯相關的CPU在相同的CPU上下文中處理收到的數據包，則可以減少等待時間并提高CPU利用率。

因此，我們可以將處理網卡中斷的CPU內核設置在網卡所在的NUMA上，從而減少跨NUMA內存訪問帶來的額外開銷，提高網絡處理性能。

3.2磁盤參數調整

3.2.1磁盤讀取預取參數

/sys/block/sdx/queue/read ahead。該參數對于順序讀取非常有用。意思是，一次提前看多少內容，不管實際需要多少。默認情況下，一次讀取128kb遠小于您想要讀取的內容。設置大一點對于讀取大文件非常有用，可以有效減少讀尋道的次數。該參數可通過使用塊dev–setra進行設置。setra設置了多少個扇區，因此實際字節除以2。例如，設置512實際讀取256個字節。

原始服務器值是128kb，它被設置為4096Kb。

3.2.2緩存寫入磁盤的參數調整

/proc/sys/vm/dirtyratio從20更改為40

此參數控制文件系統的文件系統寫緩沖區的大小。單位是百分比，表示系統內存的百分比。它表示當寫緩沖區用完系統內存時，它開始向磁盤寫入數據。如果增加，更多的系統內存將用于磁盤寫緩沖，系統的寫性能也將大大提高。

/proc/sys/VM/dirty background ratio從10更改為20

此參數控制文件系統的pdflush進程以及何時刷新磁盤。是單位百分比，表示系統內存的百分比。這意味著當寫緩沖區用完系統內存時，pdflush開始向磁盤寫入數據。

如果增加，更多的系統內存將用于磁盤寫緩沖，系統的寫性能也將大大提高。

/proc/sys/VM/dirty write back centi secs從500更改為800

此參數控制內核的臟數據刷新進程pdflush的運行間隔。單位是1/100秒。默認值為500，即5秒。

/proc/sys/VM/dirty expire centi secs從3000更改為30000。

該參數聲明Linux內核寫緩沖區中的數據為“舊”后，pdflush進程開始考慮將其寫入磁盤。單位是1/100秒。默認是30000，也就是說即使30秒的數據是舊的，也會刷新磁盤。

對于特別重載的寫操作，適當降低這個值也是好的，但是不能降低太多，因為降低太多會導致IO增加過快。

3.3應用程序調整

3.3.1優化數量的減少

調整大數據平臺上的reduce設置，使最大reduce數由200改為500，性能明顯提升。

3.3.2 Reduce并行復制參數maprd.reduce.parallel.copies優化

reduce的并發副本數默認為5，后來調整為30可以增加Reduce的最大并發副本數。

調優后，最終大數據任務執行時間有了顯著提升。

四總結

調優后，任務在泰山集群服務器上的執行時間明顯改善。相關想法總結如下:

分析確認大數據任務執行各階段耗時，重點關注耗時階段，提高降低并發，充分利用泰山多核優勢。

找出性能瓶頸，優化服務器各子模塊的參數。

特別聲明：以上文章內容僅代表作者本人觀點，不代表ESG跨境電商觀點或立場。如有關于作品內容、版權或其它問題請于作品發表后的30日內與ESG跨境電商聯系。