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

一 問題背景

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

二 原因分析

l? 業務場景分析

本場景下的大數據任務主要對數據進行mapreduce操作，該任務包含兩個子任務，第一個子任務的map（每個map的大小為128M）個數為4300左右（這些map任務都是分散在不同的服務器上，TaiShan集群有6400+個核可以處理,可以充分利用TaiShan多核優勢），map執行時間為10分鐘，但是reduce個數固定寫為200個（即最多有200個核并行處理reduce任務），reduce執行時間為1小時30分鐘左右,耗時較長，同時reduce個數相比map個數很少，不能充分利用TaiShan多核優勢，第二個子任務也是reduce階段耗時較長

l? 服務器基礎性能分析

在大數據任務執行時，cpu利用率不高，磁盤io以及網卡IO都沒有瓶頸，不過網卡中斷需要進行綁核，同時磁盤緩存參數可以進行調優來提升性能

三 解決方案

3.1 網卡調優

3.1.1 中斷綁核

中斷親和度描述為可以為特定中斷提供響應的一組CPU，如果應用程序可以通過關聯到相關的CPU，在相同的CPU上下文中處理接收到的數據包，則可以減少等待時間，提高CPU利用率。

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

3.2 磁盤參數調優

3.2.1 磁盤讀預取參數

/sys/block/sdX/queue/read_ahead，這個參數對順序讀非常有用，意思是，一次提前讀多少內容，無論實際需要多少。默認一次讀 128kb 遠小于要讀的，設置大些對讀大文件非常有用，可以有效的減少讀 seek 的次數，這個參數可以使用 blockdev –setra 來設置，setra 設置的是多少個扇區，所以實際的字節是除以2，比如設置 512 ，實際是讀 256 個字節.

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

3.2.2 緩存寫入磁盤參數調整

/proc/sys/vm/dirty_ratio 從20改成40

這個參數控制文件系統的文件系統寫緩沖區的大小，單位是百分比，表示系統內存的百分比，表示當寫緩沖使用到系統內存多少的時候，開始向磁盤寫出數據。增大之會使用更多系統內存用于磁盤寫緩沖，也可以極大提高系統的寫性能。

/proc/sys/vm/dirty_background_ratio 從10改為20

這個參數控制文件系統的pdflush進程，在何時刷新磁盤。單位是百分比，表示系統內存的百分比，意思是當寫緩沖使用到系統內存多少的時候，pdflush開始向磁盤寫出數據。

增大之會使用更多系統內存用于磁盤寫緩沖，也可以極大提高系統的寫性能。

/proc/sys/vm/dirty_writeback_centisecs 從500改為800

這個參數控制內核的臟數據刷新進程pdflush的運行間隔。單位是 1/100 秒。缺省數值是500，也就是 5 秒

/proc/sys/vm/dirty_expire_centisecs 從3000改為30000

這個參數聲明Linux內核寫緩沖區里面的數據多“舊”了之后，pdflush進程就開始考慮寫到磁盤中去。單位是 1/100秒。缺省是 30000，也就是 30 秒的數據就算舊了，將會刷新磁盤。

對于特別重載的寫操作來說，這個值適當縮小也是好的，但也不能縮小太多，因為縮小太多也會導致IO提高太快

3.3 應用程序調優

3.3.1 Reduce個數優化

在大數據平臺調整reduce設置，使最大reduce個數從原來的200改為500，性能提升明顯

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

Reduce的并發拷貝數默認是5，后來調整至30可以提升reduce的最大并發拷貝數

經過調優，最終大數據任務執行時間有明顯提升

四總結

調優后，TaiShan集群服務器上任務執行時間有明顯改善。對相關思路總結如下：

l? 分析確認大數據任務執行時各個階段的耗時，重點分析耗時階段，提升reduce并發，充分利用TaiShan多核優勢。

l? 明確性能瓶頸，并對服務器各個子模塊進行參數調優。

任務調度 大數據

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。