作为一次复盘,有些截图和报错信息不是很到位、完整。当时没记录的,就只能从浏览器的历史页面中扒。简要记录吧
目录
(4)集群运行中报错No space available in any of the local directories.
(6)报错error in shuffle in InMemoryMerger - Thread to merge in-memory shuffled map-outputs
1、环境:
Ubuntu18.4,Java1.8.0,Hadoop3.1.3
Hadoop集群基于docker创建,docker容器内的环境同上
2、任务概述:实现好友推荐
- 输入:输入数据为文本文件,每一行分别包括用户ID(user_id)和它的直接好友ID(friend_id)。user_id和friend_id用‘TAB’分隔。
- 输出:输出格式要求如下:每一行为USER: F (M: [I1, I2, I3, ….]), … 其中F是推荐给USER的一个好友,M是共同好友数量;I1, I2, I3,…是共同好友的ID。
3、遇到的问题及解决过程
本次mapreduce程序共分为3个job执行。输入文件51.5MB。第一个job的输出文件为25MB,第二个job的输出文件为7.02GB,第三个job(最终的)输出文件为5.7GB
(1)伪分布式下,job2的reduce函数卡住
正常的终端输出应该会显示map的进度和reduce的进度,如`map 100% reduce 23%`。在反复运行几次,每次都是如上页面持续近两三个小时后,改用集群去跑程序
(2)集群中,节点unhealthy
参考Hadoop集群nodes unhealthy解决方法,是由于内存不足导致的。
并参考[hadoop]3.0.0以上版本运行hadoop-mapreduce-examples的pi官方示例(踩坑日记),做出以下修改:
在yarn-site.xml中添加以下两部分:
第一块:
<property> <name>yarn.nodemanager.disk-health-checker.min-healthy-disks</name> <value>0.0</value> </property> <property> <name>yarn.nodemanager.disk-health-checker.max-disk-utilization-per-disk-percentage</name> <value>100.0</value> </property>
其中min和max规定了上限和下限,上限为磁盘使用的100%。
第二块:
<property> <name>yarn.resourcemanager.hostname</name> <value>master</value> </property> <property> <name>yarn.nodemanager.aux-services</name> <value>mapreduce_shuffle</value> </property> <property> <name>yarn.log-aggregation-enable</name> <value>true</value> </property> <property> <name>yarn.log-aggregation.retain-seconds</name> <value>604800</value> </property>
又出现报错:
Invalid host name: local host is: "h01/172.18.0.2"; destination host is: "master":8032;
是因为添加的第二部分的property中,yarn.resourcemanager.hostname的值设置成master,而我的hostname是h01
由于我只需要解决unhealthy的问题,所以第二块的配置可以直接不加。将其删去后,该报错解决。
反思:
上一次在集群跑内置的wordcount程序时,也出现了node unhealthy的情况,解决方案就是在yarn-site.xml中修改配置。这次没有多加考虑,直接沿用,导致错误。在修改配置文件的时候,要理解name和value的意思。同时,修改要慎重。
(3)主机的配置文件修改后没有分发
第一次不知道分发这个操作,直接是重新配置镜像,然后创建容器。一开始用newuhadoop镜像(彼时正在用的)创建新容器,然后在这个新容器中添加刚刚的yarn-site.xml配置,再commit成新的镜像newuhadoop2,用新的镜像创建新的容器使用。
但是出现报错:找不到网络
Error response from daemon: network hadoop not found.
这个名为hadoop的虚拟桥接网络是在下载docker后马上就设置的,通过`docker network ls`命令查看也的确存在。不清楚not found的原因,由于心情暴躁,直接将镜像和容器全都删了(Ubuntu18.04的镜像没删)
然后重新都下载一遍。但是当时,阿里云的下载变得特别慢…光是jdk就要20多分钟,有异于往常。检查apt中的源,并没有复制错。最终即便很慢但也完成了。
(4)集群运行中报错No space available in any of the local directories.
错误发生在第二个job的map完成的阶段
1.修改job history server配置
抱着对Low Disk Space的怀疑,我先尝试解决其他错误。
注意到(上一张图的)retry前的这么一句话:Application state is completed. FinalApplicationStatus=FAILED. Redirecting to job history server。于是去修改job history server配置
参照解决:Application state is completed. FinalApplicationStatus=FAILED. Redirecting to job history server,修改mapred-site.xml历史服务器的配置
<!--history address-->
<property>
<name>mapreduce.jobhistory.address</name>
<value>hadoop01:10020</value>
</property>
<!--history web address-->
<property>
<name>mapreduce.jobhistory.webapp.address</name>
<value>hadoop1:19888</value>
</property>
修改后,按照文章中的顺序,scp完成分发、重启hadoop、启动历史服务器(这篇文章的评论里还有我的备注)
出现报错:
又犯了类似的错误,别人的主机名是hadoop01,而我的是h01,需要在修改配置的时候做相应的改动。
mapred-site.xml的配置改为:
<!--history address-->
<property>
<name>mapreduce.jobhistory.address</name>
<value>h01:10020</value>
</property>
<!--history web address-->
<property>
<name>mapreduce.jobhistory.webapp.address</name>
<value>h01:19888</value>
</property>
2.给虚拟机扩容
实践证明修改历史服务器配置并不能解决问题。于是听他的话,他空间不够,我就给更多空间
- 虚拟机:删cache、tmp等一些缓存文件
- 扩容:原来是50G,再新增30G磁盘,用GParted扩充分区
- 系统内存大小:从6G扩充至8G
这一招,虽然没有完全解决问题,但至少解决了一部分问题……job2可以完整地跑完了
(5)任务被killed
上述扩容之后,能顺利跑进job3的map阶段,但此时已经很卡,出现了两种情况:(一共试了大概四五次,两种情况各占一半)
- 虚拟机死机了,电脑卡在那个画面,鼠标没有办法点动
- 虚拟机死机了一会儿,然后终端突然跳出来一行“killed”,任务被强行终止。
网上说是由于内存不足,但没有给出具体解决办法
由于缺少报错信息,只有一行“killed”或者没有,网上关于“killed”也没有具体的解决方案。联想到同学在mac的伪分布式上跑完了全程,于是采用下策:把job2的结果文件取回本地,虚拟机伪分布式上单独运行job3
(6)报错error in shuffle in InMemoryMerger - Thread to merge in-memory shuffled map-outputs
伪分布式上跑job3,可以将map阶段跑完。在reduce跑了将近一大半的时候,报错:
error in shuffle in InMemoryMerger - Thread to merge in-memory shuffled map-outputs
原因是shuffle阶段内存溢出。参考MapReduce 在Shuffle阶段 内存溢出原因分析及处理方法和$ShuffleError: error in shuffle in OnDiskMerger - Thread to merge on-disk map-outputs
在mapred-site.xml中修改,将mapreduce.reduce.shuffle.input.buffer.percent的value设置成0.3,降低shuffle使用的内存比例。
反思:
在集群中出现killed的情况时,是否也可以修改mapred-site.xml中与内存相关的配置,来解决问题呢?后知后觉,未证实。
至此,整个程序终于跑结束了。总结一下:1、双十一已经在买新硬盘了。2、修改配置文件时,搭配网上的详解使用。3、好的解决办法有:解决问题和卸了重来
文中若有见解有误、不全面不周到的地方,欢迎指出!