paulwong
          

          

          



          
	
					
	
          
		
          
			hadoop優化
		
          
		

          1. 
 
網絡帶寬
            Hadoop集群的服務器在規劃時就在統一的交換機下，這是在官方文檔中建議的部署方式。

            但是我們的這臺交換機和其他交換機的互聯帶寬有限，所以在客戶端遇到了HDFS訪問速度慢的問題。

            把操作集群的客戶端也聯入DataNode的交換機內部，解決了這個問題。

          2. 系統參數
            對ulimit -c的修改也是官方文檔建議的修改，在集群只有10臺服務器時，并沒有遇到問題。
            隨著機器增加和任務增加，這個值需要改的更大。

          3. 配置文件管理
            這個集群用的是Cloudera發行的版本，配置文件默認存在/etc/hadoop/conf位置。這是一個只有root才能修改的位置。

            為了修改方便，我把配置文件統一保存在一臺機器上，修改后用腳本分發。保證所有服務器都是統一的配置。

          4. mapred.tasktracker.map.tasks.maximum
            這個參數控制每個TaskTracker同時運行的Map任務數。

            以前的設置是和CPU核數相同的，偶爾遇到任務擠占DataNode資源的問題。

            現在改成map+reduce+1==num_cpu_cores。

          5.  嚴格控制root權限
            Cloudera的發行版會創建一個hadoop用戶，各種守護進程都應該以這個用戶運行。

            曾經有誤操作（/usr/lib/hadoop/bin/hadoop datanode &）導致本地的數據目錄被root寫入新文件，于是正確啟動的hadoop用戶進程無法讀寫。

            所以現在的集群服務器不提供日常的root權限訪問。

          6. Java的GC模式
            在mapred.child.java.opts和HADOOP_OPTS都增加了-XX:+UseConcMarkSweepGC。

            JDK的文檔中推薦現代多核處理器系統，采用這種GC方式，可以充分利用CPU的并發能力。

            這個改動對性能的積極影響很大。

          7. 選擇正確的JDK
            這個集群有部分服務器的JDK用的是32位版本，不能創建-Xmx4g以上的進程。
            統一為x64版本的JDK。

          8. mapred.reduce.slowstart.completed.maps
            這個參數控制slowstart特性的時機，默認是在5%的map任務完成后，就開始調度reduce進程啟動，開始copy過程。

            但是我們的機器數量不多，有一次大量的任務堆積在JobTracker里，每個TaskTracker的map和reduce slots都跑滿了。

            由于map沒有足夠資源迅速完成，reduce也就無法結束，造成集群的資源互相死鎖。
            把這個參數改成了0.75，任務堆積的列表從平均10個，變成了3個。

          9. mapred.fairscheduler.preemption
            這個參數設為了true。以便fairscheduler在用戶最小資源不能滿足時，kill其他人的任務騰出足夠的資源。

            集群運行著各種類型的任務，有些map任務需要運行數小時。這個參數會導致這類任務被頻繁kill，幾乎無法完成。曾經有個任務在7小時內被kill了137次。

            可以通過調整fairscheduler的pool配置解決，給這種任務單獨配置一個minMap==maxMap的pool。

          10. mapred.jobtracker.completeuserjobs.maximum
            限制每個用戶在JobTracker的內存中保存任務的個數。
            因為這個參數過大，我們的JobTracker啟動不到24小時就會陷入頻繁的FullGC當中。

            目前改為5，JT平穩運行一天處理1500個任務，只占用800M內存。

            這個參數在>0.21.0已經沒有必要設置了，因為0.21版本改造了completeuserjobs的用法，會盡快的寫入磁盤，不再內存中長期存在了。

          11. mapred.jobtracker.update.faulty.tracker.interval和mapred.jobtracker.max.blacklist.percent
            一個寫錯的任務，會導致一大批TaskTracker進入黑名單，而且要24小時才能恢復。這種狀況對中小規模的集群性能影響是非常大的。只能通過手工重啟TaskTracker來修復。所以我們就修改了部分JobTracker的代碼，暴露了兩個參數：

            mapred.jobtracker.update.faulty.tracker.interval控制黑名單重置時間，默認是24小時不能改變，我們現在改成了1小時。

            mapred.jobtracker.max.blacklist.percent控制進入黑名單TT的比例，我們改成了0.2。
            我正在補充這兩個參數的TestCase，準備提交到trunk中。

          12. 多用hive少用streaming
            由于streaming的方便快捷，我們做了很多基于它的開發。但是由于streaming的任務在運行時還要有一個java進程讀寫stdin/out，有一定的性能開銷。

            類似的需求最好改用自定義的Deserializer+hive來完成。
           

		
          
			posted on 2012-09-24 23:28 paulwong 閱讀(822) 評論(0)  編輯  收藏  所屬分類: HADOOP 、云計算 
		
          
	
          
	
	





          
	    
    




          








          

				

          



    







          
        
	




主站蜘蛛池模板：
射洪县|
仙游县|
漳州市|
叙永县|
北海市|
安图县|
扶沟县|
巴马|
花垣县|
和田市|
米泉市|
游戏|
呼伦贝尔市|
阿瓦提县|
富裕县|
怀远县|
克什克腾旗|
兰溪市|
哈尔滨市|
南城县|
卓资县|
麻江县|
驻马店市|
桐庐县|
尼玛县|
鹿邑县|
红桥区|
郑州市|
拉孜县|
仪征市|
五华县|
皋兰县|
射阳县|
商水县|
临沧市|
延安市|
双江|
综艺|
福建省|
丰城市|
慈溪市|