hadoop 性能調優 重要參數設置技巧（轉載）

這裏主要針對Mapreduce的性能調優。

這裏主要涉及的參數包括：

HDFS：

dfs.block.size

Mapredure：

io.sort.mb

io.sort.spill.percent

mapred.local.dir

mapred.map.tasks & mapred.tasktracker.map.tasks.maximum

mapred.reduce.tasks & mapred.tasktracker.reduce.tasks.maximum

mapred.reduce.max.attempts

mapred.reduce.parallel.copies

mapreduce.reduce.shuffle.maxfetchfailures

mapred.child.java.opts

mapred.reduce.tasks.speculative.execution

mapred.compress.map.output & mapred.map.output.compression.codec

mapred.reduce.slowstart.completed.maps

這裏一共列出了十六個參數，這十六個參數基本上能知足通常狀況下，不針對特定場景應用的性能調優了，下面我將以Terasort爲例，詳述這些參數的做用已經如何配比調優。

       hadoop的HDFS做爲mapreduce的基礎分佈式文件系統，對mapred的運行效果也有直接的影響。首先影響到咱們的性能的參數就是block.size，在網絡環境很好的集羣中，建議將這個參數提高，大小能夠到128或256或更大（默認64M）。

        可是HDFS的影響也僅限於此，並且其配置項多數都是目錄配置以及容錯，還有備份數等等，這些對於咱們性能調優意義不大。能夠舉一個例子，那就是備份數。這個參數主要是用於設置block在集羣中的備份數，這些備份將按照某種規則分配在集羣的各個機器上，默認是3備份。可是因爲mapred的map須要輸入數據，通常默認狀況是一個map一個block，那麼當你在集羣起job，一個job拉起來N多的map在一個機器執行時，若是這個map的輸入數據是本地的，那麼顯然map的執行將會更快，由於不須要等待網絡傳輸。拿四個節點爲例，若是你設置三備份，那麼你無論存什麼數據，任何一臺機器上能夠存數的你的數據的量都是3/4,。可是若是你設置爲四備份，那麼任意一個節點上都能完整的找到你的數據，那麼無論你怎麼起job，你的map都將是本地化的。可是帶來的壞處就是磁盤開銷過大，通常大型的集羣也承受不了5備份以上的數據量，因此，基本無心義。

         下面來談談重頭戲，那就是mapred中的這些NB的參數。前置知識我相信你們都已經瞭解了（若是你還不瞭解mapred的運行機制，看這個也無心義...），首先數據要進行map，而後merge，而後reduce進程進行copy，最後進行reduce，其中的merge和copy總稱能夠爲shuffle。在你起一個job前，hadoop須要知道你要啓動多少個map，多少個renduce進程，若是你進行默認參數啓動，那麼默認只有一個map線程。（reduce也許也是一個..）這個速度是很慢的。設置map啓動個數的參數是mapred.map.tasks，reduce則是mapred.reduce.tasks。這兩個參數能夠說是對整個集羣的性能起主導型做用的參數，調試也基本上圍繞這兩個參數。那你們要問就兩個參數有什麼好來回修改的呢？其實，這兩個參數的設置配比也直接影響到其餘的參數的設置。首當其衝的就是mapred.tasktracker.map.tasks.maximum 以及 mapred.tasktracker.reduce.tasks.maximum。由於這兩個參數設置了一臺服務器上最多能同時運行的map和reduce數。如今咱們來假設一個集羣有一個namenode以及8個datanode，這是一個很客觀的集羣。咱們假設上面的數據都是三備份，那麼本地數據率爲3/8。假設你設置的map.tasks=128，reuce.tasks=64，那麼你的對應的兩個maximum就應該分別爲16以及8或是更高。由於這樣才能保證你的全部map和reduce的任務都是分別同時啓動的，若是你的設置reduce的maximum爲7，那麼你將獲得很是糟糕的結果，由於這樣8臺機器同時能夠運行的reduce數量爲56了，比你設置的64差8個進程，這八個進程將會處於pending狀態，直到某些正在運行的reduce完成它才能補上運行，勢必大幅度的增長了運行時間。固然，這也不是越大越好，由於map有很長的一段時間是和reduce進程共存的，共存的時間取決於你設置的mapred.reduce.slowstart.completed.maps，若是你設置爲0.6.那麼reduce將在map完成60%後進入運行態。因此說，若是你設置的map和reduce參數都很大，勢必形成map和reduce爭搶資源，形成有些進程飢餓，超時出錯，最大的可能就是socket.timeout的出錯，網絡過於繁忙。因此說，這些須要根據集羣的性能，適當調試添加和減小，以達到最好的效果。那麼，map和reduce之間是怎樣的配比比較好呢？apache官網給了咱們一些建議，好比設置reduce與map，他們之間有一個具體的公式。可是實際狀況老是不能用公式來套用的（不然就不須要系統工程師了...）。通常狀況下，當你設置好map和reduce進程數後，你能夠經過hadoop的mapred的頁面入口（http://namenode:50030/jobdetai.jps）查看map和reduce進度，若是你發現reduce在33%時，map正好提前一點點到100%，那麼這將是最佳的配比，由於reduce是在33%的時候完成了copy階段，也就是說，map須要再reduce到達33%以前完成全部的map任務，準備好數據。千萬不能讓reduce在等待，可是可讓map先完成。

          OK！這個重點的搞完以後咱們在看看兩個息息相關的參數，io.sort.mb和mapred.child.java.opts。由於每個map或是reduce進程都是一個task，都會對應啓動一個JVM，因此其實java.opts也與你啓動的map和reduce數以及別的一些jvm敏感的參數有關。既然task運行在JVM裏面，那麼，我這裏所要提到的sort.mb 也是分配在JVM中的，這個值是用來設置到底我一個map sort的可用buffer大小是多少，若是map在內存中sort的結果達到一個特定的值，就會被spill進入硬盤。具體這個值是等於mb*io.sort.spill.percent.。按照一般的設置方式，爲了讓jvm發揮最佳性能，通常設置JVM的最大可用內存量爲mb設置的內存量的兩倍。那麼mb的內存量又根據什麼設置呢？它主要是與你的一個map的結果數據量有關。若是一個map的結果數據量爲600M，那麼若是你設置的mb*io.sort.spill.percent.=200M，那麼將進行3次spill進入硬盤，而後map完成後再將數據從硬盤上取出進行copy。因此，這個mb設置若是是600M的話，那麼就不須要進行此次硬盤訪問了，節省了不少時間。可是最大的問題是內存耗費很大。若是mb是600M，那麼jvm.opts將須要設置爲1G以上，那麼，按照上例，你同時啓動16個map和8個reduce 的話，那麼你的內存至少應該有24G。因此，這裏的設置也要慎重，由於畢竟你的服務器還要跑不少其餘的服務。

         下面就講一下別的一些有影響的參數，按照通常的設置方法就能夠。首先是針對磁盤和磁盤IO的，mapred.local.dir，這個參數最好設置的跟你的磁盤數相同，你的磁盤應該每個磁盤都單獨設置爲RAID0，而後將全部磁盤配置成多路徑在這個配置項下，那麼HDFS在決定數據存儲時會順序循環存儲，保證全部磁盤數據量的一致性，也提高了總體磁盤的IO速度。那麼針對於網絡，主要是有reduce和map同時運行時須要慎重考慮。mapred.reduce.parallel.copies與mapreduce.reduce.shuffle.maxfetchfailures這些參數都是對網絡有一些影響的。第一個是reduce能夠進行的最大並行拷貝線程數，這些線程會同時從不一樣的datanode上取map結果，而第二個出錯重試次數過多對於不少咱們的應用都是下降性能的一個問題。由於通常一個job重試了1次沒有成功那基本之後不管怎麼重試都是不會成功的，重試了不成功沒關係，關鍵是這個重試還大量的消耗系統的資源，讓其餘的線程可能也由於starvation 而進入重試狀態，惡性循環了。若是說你的網絡確實很成瓶頸，千兆網都達不到，那麼建議打開mapred.compress.map.output壓縮選項，並配置 mapred.map.output.compression.codec壓縮編碼格式，通常都會使用snappy，由於這種格式對於壓縮和解壓縮都相對較快。還有就是若是你的集羣是異構的，有些機器性能好，有些差，那麼建議打開mapred.reduce.tasks.speculative.execution推測性執行，有利於優化進程分配，提高集羣性能。

  

yarn下的hdfs和mr性能調優參數一覽表

mr核心的幾個參數：

conf/mapred-site.xml：

mapreduce.task.io.sort.mb

任務內部排序緩衝區大小默認100m

mapreduce.map.sort.spill.percent

Map階段溢寫文件的閾值（排序緩衝區大小的百分比）默認0.8

mapreduce.reduce.shuffle.parallelcopies

Reduce Task啓動的併發拷貝數據的線程數目默認5

mapreduce.map.memory.mb

每一個Map Task須要的內存量默認1024m

mapreduce.map.java.opts

map的最大累計內存如：-Xmx1024M

mapreduce.reduce.memory.mb

每一個Reduce Task須要的內存量默認1024m

mapreduce.reduce.java.opts

全部reduce加起來的總和內存大小如：-Xmx1024M 

mapreduce.job.jvm.num.tasks 

默認爲1，設置爲 -1，重用jvm

 

dfs io：

io.file.buffer.size

默認4k，根據須要適當調高

 

namenode性能調優參數：

dfs.namenode.handler.count

主要是namenode處理datanode的rpc進程數默認是100

 

其餘參數：

mapreduce.job.reduce.slowstart.completed.maps 

默認值是0.05,也就是map task完成數目達到5%時,開始啓動reduce task

 

下述意義不大

conf/yarn-site.xml

yarn.nodemanager.resource.memory-mb

NodeManager總的可用物理內存,默認值是8192MB,通常狀況下不要修改

yarn.nodemanager.vmem-pmem-ratio

每使用1MB物理內存，最多可用的虛擬內存數默認2.1

yarn.nodemanager.resource.cpu-vcores

參數解釋：NodeManager總的可用虛擬CPU個數。默認值：8