最近的hdfs集群出了一些故障，今天總結(jié)一下hadoop的幾個(gè)具體的性能調(diào)優(yōu)方法

1）HDFS參數(shù)調(diào)優(yōu)hdfs-site.xml

（1）dfs.namenode.handler.count=20 * log2(Cluster Size)，比如集群規(guī)模為8臺(tái)時(shí)，此參數(shù)設(shè)置為60

Thenumber of Namenode RPC server threads that listen to requests from clients. Ifdfs.namenode.servicerpc-address is not configured then Namenode RPC serverthreads listen to requests from all nodes.

NameNode有一個(gè)工作線程池，用來(lái)處理不同DataNode的并發(fā)心跳以及客戶端并發(fā)的元數(shù)據(jù)操作。對(duì)于大集群或者有大量客戶端的集群來(lái)說，通常需要增大參數(shù)dfs.namenode.handler.count的默認(rèn)值10。設(shè)置該值的一般原則是將其設(shè)置為集群大小的自然對(duì)數(shù)乘以20，即20logN，N為集群大小。

（2）編輯日志存儲(chǔ)路徑dfs.namenode.edits.dir設(shè)置與鏡像文件存儲(chǔ)路徑dfs.namenode.name.dir盡量分開，達(dá)到最低寫入延遲，提高集群的讀寫方面性能

2）YARN參數(shù)調(diào)優(yōu)yarn-site.xml

（1）情景描述：總共7臺(tái)機(jī)器，每天幾億條數(shù)據(jù)，數(shù)據(jù)源->Flume->Kafka->HDFS->Hive

面臨問題：數(shù)據(jù)統(tǒng)計(jì)主要用HiveSQL，沒有數(shù)據(jù)傾斜，小文件已經(jīng)做了合并處理，開啟的JVM重用，而且IO沒有阻塞，內(nèi)存用了不到50%。但是還是跑的非常慢，而且數(shù)據(jù)量洪峰過來(lái)時(shí)，整個(gè)集群都會(huì)宕掉。基于這種情況有沒有優(yōu)化方案。

（2）解決辦法：

內(nèi)存利用率不夠。這個(gè)一般是Yarn的2個(gè)配置造成的，單個(gè)任務(wù)可以申請(qǐng)的最大內(nèi)存大小，和Hadoop單個(gè)節(jié)點(diǎn)可用內(nèi)存大小。調(diào)節(jié)這兩個(gè)參數(shù)能提高系統(tǒng)內(nèi)存的利用率。

（a）yarn.nodemanager.resource.memory-mb

表示該節(jié)點(diǎn)上YARN可使用的物理內(nèi)存總量，默認(rèn)是8192（MB），注意，如果你的節(jié)點(diǎn)內(nèi)存資源不夠8GB，則需要調(diào)減小這個(gè)值，而YARN不會(huì)智能的探測(cè)節(jié)點(diǎn)的物理內(nèi)存總量。

（b）yarn.scheduler.maximum-allocation-mb

單個(gè)任務(wù)可申請(qǐng)的最多物理內(nèi)存量，默認(rèn)是8192（MB）。

3）Hadoop宕機(jī)

（1）如果MR造成系統(tǒng)宕機(jī)。此時(shí)要控制Yarn同時(shí)運(yùn)行的任務(wù)數(shù)，和每個(gè)任務(wù)申請(qǐng)的最大內(nèi)存。調(diào)整參數(shù)：yarn.scheduler.maximum-allocation-mb（單個(gè)任務(wù)可申請(qǐng)的最多物理內(nèi)存量，默認(rèn)是8192MB）

（2）如果寫入文件過量造成NameNode宕機(jī)。那么調(diào)高Kafka的存儲(chǔ)大小，控制從Kafka到HDFS的寫入速度。高峰期的時(shí)候用Kafka進(jìn)行緩存，高峰期過去數(shù)據(jù)同步會(huì)自動(dòng)跟上。