HADOOP优化

来源 http://www.blogjava.net/paulwong/archive/2012/09/24/388458.html

 

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来完成。