记一次hadoop磁盘空间满的异常

╰+攻爆jí腚メ 2022-04-13 11:08 818阅读 0赞

\[b\]\[color=green\]\[size=large\]本事故，发生在测试的环境上，虽然不是线上的环境，但也是一次比较有价值的事故。  
  
  
起因：公司里有hadoop的集群，用来跑建索引，PHP使用人员，调用建索引的程序时，发现MapReduce集群启动不起来了，报IOException异常，具体的异常没有记录，大致的意思就是磁盘空间满了，导致创建文件失败！  
  
  
下面散仙模拟当时的环境，接到问题后，第一件事就是先查看centos系统的磁盘使用率  
执行命令 df -h ，查看当前占用情况：  
\[/size\]\[/color\]\[/b\]

Filesystem            Size  Used Avail Use% Mounted on
    /dev/mapper/VolGroup-lv_root
                           11G  8.7G  1.3G  100% /
    tmpfs                 1.9G     0  1.9G   0% /dev/shm
    /dev/sda1             485M   37M  423M   8% /boot

\[b\]\[size=large\]发现磁盘使用100%，导致空间不足，从而使Hadoop启动作业时的，需要建立临时的文件的空间都没有，故出现了，文章开头的一幕。  
  
找到原因后，就好办了，查看当前系统下文件占用情况，删除几个比占空间比较大而且无关紧要的文件，当然我们这是在测试的环境上，一般线上挂载的磁盘都比较大，出现这样的异常情况，应该非常小。  
  
执行命令： ll -h 查看某些文件目录的大小  
这个命令散仙测，某些时候，不太好使，故使用下面命令  
du -sh \* 查看空间文件占用情况：  
\[/size\]\[/b\]

[search@bjdevfse02 ~]$ du -sh *
    4.0K    beginzk.sh
    4.0K    clearhadoop.sh
    0       hadoop
    95M     hadoop-1.2.1
    214M    hadoop-2.2.0
    152K    hadoopconf
    345M    hadoop-dd
    4.0K    script
    0       solr
    188M    solr-4.3.0
    52M     solr-4.3.1
    704K    solrconf
    4.0K    stopzk.sh
    4.0K    synconf.sh
    36K     tmp
    0       zk
    8.0K    zkconf
    39M     zkdata
    40M     zookeeper-3.4.5
    4.0K    zookeeper.out

\[b\]\[color=olive\]\[size=large\]删除几个文件后，磁盘率达到一个启动MR作业的要求，然后再次运行MR作业时，发现又报异常，看log发现，Hadoop由于磁盘满，而导致进入安全模式，所以导致提交失败，异常如下：\[/size\]\[/color\]\[/b\]  
  
\[img\]http://dl2.iteye.com/upload/attachment/0099/0808/afa842ab-693e-3d8d-8d7a-9eaf1ef511c2.jpg\[/img\]  
\[b\]\[color=green\]\[size=large\]知道原因后，执行如下命令，退出安全模式  
hadoop dfsadmin -safemode leave\[/size\]\[/color\]\[/b\]  
  
\[b\]\[color=olive\]\[size=large\]再次提交MR作业后，正常运行！\[/size\]\[/color\]\[/b\]  
  
\[img\]http://dl2.iteye.com/upload/attachment/0099/0810/553d6ae6-9b07-3c66-9a0f-e0c8b5154bcd.jpg\[/img\]  
  
\[b\]\[color=green\]\[size=large\]总结：  
1，遇到问题时，第一反应，尽可能的先把原始信息，异常什么的保留下来，便于分析，有的可能没有log记录，或者log比较大查找不方便，用手机拍照，或粘贴复制什么的。  
  
2，根据异常信息，尽可能直接准确异常的原因，如果实在定位不到，可能还需要分析最近几天系统里发生的变化，然后一个个定位，排除。  
  
3，解决成功后，尽可能记录下来，发生的原因是什么，然后排除的方法，等等一些心得体会，最后，分享给团队或同事，避免以后发生此种类似的事，或者发生后，便于快速根据文档恢复，这一点非常重要。  
\[/size\]\[/color\]\[/b\]