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来完成。
posted @ 2013-08-08 10:40  小湖海  阅读(212)  评论(0编辑  收藏  举报