码迷,mamicode.com
首页 > 其他好文 > 详细

一次JobTracker拥堵问题排查过程

时间:2015-01-12 16:36:49      阅读:173      评论:0      收藏:0      [点我收藏+]

标签:hadoop   jobtracker   拥堵   吞吐量   阻塞   

Hadoop版本 1.0.3

问题描述:

    随着每日MR作业数目渐增,用户反映提交作业时经常阻塞,也就是JobTracker发生了拥堵。这种情况开始频繁出现,我们调大JobTracker端的RPC Handler线程个数,并定时对JobTracker的栈信息进行分析,如果RPC Handler线程全部被BLOCKED住了,就Dump出栈信息,并及时发出报警。

原因及解决办法:

    经过分析几次抓取的JobTracker栈信息,发现每次JobTracker拥堵时,大家都在抢RPC里DataQueue对象的锁。

比如:计算节点/客户端向JobTracker发起的RPC调用

 

(1)     org.apache.hadoop.mapred.JobTracker getReduceTaskReports
(2)     org.apache.hadoop.mapred.JobTracker.getMapTaskReport
(3)     org.apache.hadoop.mapred.JobTracker.heartbeat
(4)     org.apache.hadoop.mapred.JobTracker.getJobStatus
….

这些方法都需要对JobTracker对象加锁(是synchronized方法,或者在函数体力对this加锁,详情可见JobTracker代码).

通过JobTracker的线程栈信息发现,大家都在抢JobTracker对象锁:

<0x000000050ce06ae8> (aorg.apache.hadoop.mapred.JobTracker)

技术分享

而持有JobTracker对象锁的为IPCHandler14线程 , 它阻塞在调用DFSClient.writeChunk方法,该方法需要向dataQueue里写数据.

 

技术分享

 

持有dataQueue对象锁<0x0000000753bd9a48 > (a java.util.LinkedList) 的为DataStreamer线程,它正在向HDFS写job.history文件

技术分享

 

几乎每次发生拥堵的时候,DataStreamer线程都在写History文件,写HDFS是一件非常慢的操作,那么,问题/瓶颈会不会就出在这里?

随机从HDFS的50070界面上看了下job.history文件:

惊奇地发现,blocksize只有3KB.

技术分享

     那么,问题来了,部分job.history文件非常大(MB级别,比如用户上传了dependency类型的jar包时,这个history文件就很大)

假设job.history文件有3M,blocksize为3KB的时候,需要先NameNode申请1K个block,向datanode建立1k次Pipeline….  这也难怪DataStreamer.writeChunk时会等待dataQueue对象的锁了(因为一次pipeline只能传送3kB的数据)。

    经查看JobTracker代码,发现job.hstory的块大小由参数mapred.jobtracker.job.history.block.size指定的。这个默认值是3M,不知哪位前辈出于什么原因将其改成了3KB,重新调整为3MB,JobTracker不再拥堵了。另外,我们将JobHistoryServer从JobTracker分离,单独用一台机器做JobHistoryServer以减轻JobTracker的压力。

<property>
 <name>mapred.jobtracker.job.history.block.size</name>
 <value>3145728</value>
 <description>The block size of the job history file. Since the jobrecovery
 uses job history, its important to dump job history to disk as
 soon as possible. Note that this is an expert level parameter.
  Thedefault value is set to 3 MB.
 </description>
</property>

(PS:  熟悉Hadoop1.x的都知道,JobTracker将资源管理和作业监控放在了一起,限制了JobTracker作业吞吐能力,Hadoop2.X(YARN)将JobTracker功能进行了分拆:ResourceManager和ApplicationMaster, 能从根本上解决JobTracker作业吞吐率低的问题)


一次JobTracker拥堵问题排查过程

标签:hadoop   jobtracker   拥堵   吞吐量   阻塞   

原文地址:http://blog.csdn.net/mango_song/article/details/42642931

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!