hadoop 问题排查方案
1,hadoop配置
hadoop集群的配置关系着hadoop能否利用集群的优势进行高效率地计算
2,map任务
map可能出现问题map数据倾斜,吞吐过低,或者低效的用户代码
3,reduce任务
同map一样的问题
4,硬件
这是一个比较难以发现的问题,笔者遇到一个问题。但是一旦出现这个问题产生的影响和数据倾斜是有过之而不及
5,排查问题
5.1 hadoop集群的mr任务的整个过程
5.2 排查问题的步骤
5.2.1,是否有一小部分的作业还在运行
诊断:可能来自的问题,数据倾斜(map,reduce),不可分割大文件
数据倾斜查看方式:
查看job tracker UI
查看目前runing的map ,查看在跑map的详细信息,下图status 显示了在跑的一个map的读取文件名和起始偏移量
和读入数据文件的大小(通过查看文件的大小也可以确认是否因为由于过多的小文件引起的性能低下),通过对比和已经完成
map读入数据的大小确认是否存在数据倾斜
点击上图的counters 可以查看更为详细的信息
reduce 的判断机制同上方式同上
不可分割大文件:
what:通过查看completed tasks来查看该文件是否可以大文件:
why:1处理的就是不是基于block storage 二进制文件且不能被切割,2因为事实文件压缩,导致的文件不可分割,这只是对于特定的压缩格式才产生作用。
这个问题所带来的影响就是:丧失了集群数据的并行化,和hdfs数据本地化数据,不仅仅带来极高的网络开销的,和单台机器的高负荷)
2,这个作业往期运行效率
这个通过比较每个节点输入数据大小就可以比较并判定出结果,不多说了
3,可能有其他作业在运行或者调度器有变化
4,map任务是否吞吐过低
5,reduce是否吞吐过低
1,通过查看reduce节点输入数据的大小,来进行初步诊断(借鉴前面1的方式)
2,查看shuffle和sort的执行效率 ,这个hadoop自带的job tracker无法直观的明了查看这一项,但是可以通过手动估算。
6,reduce配置数据量
7,查找硬件问题
转载于:https://my.oschina.net/osenlin/blog/502945