Hadoop如何優(yōu)化

這篇文章給大家分享的是有關(guān)Hadoop如何優(yōu)化的內(nèi)容。小編覺得挺實(shí)用的，因此分享給大家做個(gè)參考，一起跟隨小編過來看看吧。

1. 網(wǎng)絡(luò)帶寬

Hadoop集群的服務(wù)器在規(guī)劃時(shí)就在統(tǒng)一的交換機(jī)下，這是在官方文檔中建議的部署方式。但是我們的這臺(tái)交換機(jī)和其他交換機(jī)的互聯(lián)帶寬有限，所以在客戶端遇到了HDFS訪問速度慢的問題。把操作集群的客戶端也聯(lián)入DataNode的交換機(jī)內(nèi)部，解決了這個(gè)問題。

2. 系統(tǒng)參數(shù)

對(duì)ulimit -c的修改也是官方文檔建議的修改，在集群只有10臺(tái)服務(wù)器時(shí)，并沒有遇到問題。隨著機(jī)器增加和任務(wù)增加，這個(gè)值需要改的更大。

3. 配置文件管理

這個(gè)集群用的是Cloudera發(fā)行的版本，配置文件默認(rèn)存在/etc/hadoop/conf位置。這是一個(gè)只有root才能修改的位置。為了修改方便，我把配置文件統(tǒng)一保存在一臺(tái)機(jī)器上，修改后用腳本分發(fā)。保證所有服務(wù)器都是統(tǒng)一的配置。

4. mapred.tasktracker.map.tasks.maximum

這個(gè)參數(shù)控制每個(gè)TaskTracker同時(shí)運(yùn)行的Map任務(wù)數(shù)。以前的設(shè)置是和CPU核數(shù)相同的，偶爾遇到任務(wù)擠占DataNode資源的問題。現(xiàn)在改成map+reduce+1==num_cpu_cores。

5. 嚴(yán)格控制root權(quán)限

Cloudera的發(fā)行版會(huì)創(chuàng)建一個(gè)hadoop用戶，各種守護(hù)進(jìn)程都應(yīng)該以這個(gè)用戶運(yùn)行。曾經(jīng)有誤操作（/usr/lib/hadoop/bin/hadoop datanode &）導(dǎo)致本地的數(shù)據(jù)目錄被root寫入新文件，于是正確啟動(dòng)的hadoop用戶進(jìn)程無法讀寫。所以現(xiàn)在的集群服務(wù)器不提供日常的root權(quán)限訪問。

6. Java的GC模式

在mapred.child.java.opts和HADOOP_OPTS都增加了-XX:+UseConcMarkSweepGC。JDK的文檔中推薦現(xiàn)代多核處理器系統(tǒng)，采用這種GC方式，可以充分利用CPU的并發(fā)能力。這個(gè)改動(dòng)對(duì)性能的積極影響很大。

7. 選擇正確的JDK

這個(gè)集群有部分服務(wù)器的JDK用的是32位版本，不能創(chuàng)建-Xmx4g以上的進(jìn)程。統(tǒng)一為x64版本的JDK。

8. mapred.reduce.slowstart.completed.maps

這個(gè)參數(shù)控制slowstart特性的時(shí)機(jī)，默認(rèn)是在5%的map任務(wù)完成后，就開始調(diào)度reduce進(jìn)程啟動(dòng)，開始copy過程。但是我們的機(jī)器數(shù)量不多，有一次大量的任務(wù)堆積在JobTracker里，每個(gè)TaskTracker的map和reduce slots都跑滿了。由于map沒有足夠資源迅速完成，reduce也就無法結(jié)束，造成集群的資源互相死鎖。把這個(gè)參數(shù)改成了0.75，任務(wù)堆積的列表從平均10個(gè)，變成了3個(gè)。

9. mapred.fairscheduler.preemption

這個(gè)參數(shù)設(shè)為了true。以便fairscheduler在用戶最小資源不能滿足時(shí)，kill其他人的任務(wù)騰出足夠的資源。集群運(yùn)行著各種類型的任務(wù)，有些map任務(wù)需要運(yùn)行數(shù)小時(shí)。這個(gè)參數(shù)會(huì)導(dǎo)致這類任務(wù)被頻繁kill，幾乎無法完成。曾經(jīng)有個(gè)任務(wù)在7小時(shí)內(nèi)被kill了137次?？梢酝ㄟ^調(diào)整fairscheduler的pool配置解決，給這種任務(wù)單獨(dú)配置一個(gè)minMap==maxMap的pool。

10. mapred.jobtracker.completeuserjobs.maximum

限制每個(gè)用戶在JobTracker的內(nèi)存中保存任務(wù)的個(gè)數(shù)。因?yàn)檫@個(gè)參數(shù)過大，我們的JobTracker啟動(dòng)不到24小時(shí)就會(huì)陷入頻繁的FullGC當(dāng)中。目前改為5，JT平穩(wěn)運(yùn)行一天處理1500個(gè)任務(wù)，只占用800M內(nèi)存。這個(gè)參數(shù)在>0.21.0已經(jīng)沒有必要設(shè)置了，因?yàn)?.21版本改造了completeuserjobs的用法，會(huì)盡快的寫入磁盤，不再內(nèi)存中長(zhǎng)期存在了。

11.mapred.jobtracker.update.faulty.tracker.interval，mapred.jobtracker.max.blacklist.percent

一個(gè)寫錯(cuò)的任務(wù)，會(huì)導(dǎo)致一大批TaskTracker進(jìn)入黑名單，而且要24小時(shí)才能恢復(fù)。這種狀況對(duì)中小規(guī)模的集群性能影響是非常大的。只能通過手工重啟TaskTracker來修復(fù)。所以我們就修改了部分JobTracker的代碼，暴露了兩個(gè)參數(shù)：mapred.jobtracker.update.faulty.tracker.interval控制黑名單重置時(shí)間，默認(rèn)是24小時(shí)不能改變，我們現(xiàn)在改成了1小時(shí)。

mapred.jobtracker.max.blacklist.percent控制進(jìn)入黑名單TT的比例，我們改成了0.2。我正在補(bǔ)充這兩個(gè)參數(shù)的TestCase，準(zhǔn)備提交到trunk中。

12. 多用hive少用streaming

由于streaming的方便快捷，我們做了很多基于它的開發(fā)。但是由于streaming的任務(wù)在運(yùn)行時(shí)還要有一個(gè)java進(jìn)程讀寫stdin/out，有一定的性能開銷。類似的需求最好改用自定義的Deserializer+hive來完成。

感謝各位的閱讀！關(guān)于“Hadoop如何優(yōu)化”這篇文章就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，讓大家可以學(xué)到更多知識(shí)，如果覺得文章不錯(cuò)，可以把它分享出去讓更多的人看到吧！