在Hadoop伪分布式和集群运行mapreduce时，由于数据量过大而导致任务频频崩溃的辛酸史

作为一次复盘，有些截图和报错信息不是很到位、完整。当时没记录的，就只能从浏览器的历史页面中扒。简要记录吧

目录

1、环境：

2、任务概述：实现好友推荐

3、遇到的问题及解决过程

（1）伪分布式下，job2的reduce函数卡住

（2）集群中，节点unhealthy

（3）主机的配置文件修改后没有分发

（4）集群运行中报错No space available in any of the local directories.

1.修改job history server配置

 2.给虚拟机扩容

（5）任务被killed

（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中添加以下两部分：

第一块：

1.  
   <property>
2.  
   <name>yarn.nodemanager.disk-health-checker.min-healthy-disks</name>
3.  
   <value>0.0</value>
4.  
   </property>
5.  
   <property>
6.  
   <name>yarn.nodemanager.disk-health-checker.max-disk-utilization-per-disk-percentage</name>
7.  
   <value>100.0</value>
8.  
   </property>

其中min和max规定了上限和下限，上限为磁盘使用的100%。

第二块：

1.  
   <property>
2.  
   <name>yarn.resourcemanager.hostname</name>
3.  
   <value>master</value>
4.  
   </property>
5.  
   <property>
6.  
   <name>yarn.nodemanager.aux-services</name>
7.  
   <value>mapreduce_shuffle</value>
8.  
   </property>
9.  
   <property>
10.  
    <name>yarn.log-aggregation-enable</name>
11.  
    <value>true</value>
12.  
    </property>
13.  
    <property>
14.  
    <name>yarn.log-aggregation.retain-seconds</name>
15.  
    <value>604800</value>
16.  
    </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的意思。同时，修改要慎重。

yarn-site.xml参数配置详解

（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历史服务器的配置

1.  
   <!--history address-->
2.  
   <property>
3.  
   <name>mapreduce.jobhistory.address</name>
4.  
   <value>hadoop01:10020</value>
5.  
   </property>
6.  
   <!--history web address-->
7.  
   <property>
8.  
   <name>mapreduce.jobhistory.webapp.address</name>
9.  
   <value>hadoop1:19888</value>
10.  
    </property>

修改后，按照文章中的顺序，scp完成分发、重启hadoop、启动历史服务器（这篇文章的评论里还有我的备注）

出现报错： 

 又犯了类似的错误，别人的主机名是hadoop01，而我的是h01，需要在修改配置的时候做相应的改动。

mapred-site.xml的配置改为：

1.  
   <!--history address-->
2.  
   <property>
3.  
   <name>mapreduce.jobhistory.address</name>
4.  
   <value>h01:10020</value>
5.  
   </property>
6.  
   <!--history web address-->
7.  
   <property>
8.  
   <name>mapreduce.jobhistory.webapp.address</name>
9.  
   <value>h01:19888</value>
10.  
    </property>

 2.给虚拟机扩容

实践证明修改历史服务器配置并不能解决问题。于是听他的话，他空间不够，我就给更多空间

• 虚拟机：删cache、tmp等一些缓存文件
• 扩容：原来是50G，再新增30G磁盘，用GParted扩充分区
• 系统内存大小：从6G扩充至8G

这一招，虽然没有完全解决问题，但至少解决了一部分问题……job2可以完整地跑完了

（5）任务被killed

上述扩容之后，能顺利跑进job3的map阶段，但此时已经很卡，出现了两种情况：（一共试了大概四五次，两种情况各占一半）

1. 虚拟机死机了，电脑卡在那个画面，鼠标没有办法点动
2. 虚拟机死机了一会儿，然后终端突然跳出来一行“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、好的解决办法有：解决问题和卸了重来

文中若有见解有误、不全面不周到的地方，欢迎指出！

这篇好文章是转载于：学新通技术网