2016年八月月 发布的文章

[YARN] NodeManager因为ContainerMetric导致OOM

现象描述

之前hadoop2.7.1的集群,经常运行一段时间后会触发OOM,导致上面的map需要重跑,能想到的一种方案是调整GC参数,利用GC回收器对内存进行回收,另外一种情况则感觉代码可能处理有问题。

关键日志:

2016-07-05 09:35:40,907 WARN org.apache.hadoop.ipc.Client: Unexpected error reading responses on connection Thread[IPC Client (2069725879) connection to rmhost:8031 from yarn,5,main]
java.lang.OutOfMemoryError: Java heap space
        at sun.nio.ch.EPollArrayWrapper.<init>(EPollArrayWrapper.java:120)
        at sun.nio.ch.EPollSelectorImpl.<init>(EPollSelectorImpl.java:68)

后来调整GC参数,追踪到底哪里出了问题,以下是参数参考

YARN_NODEMANAGER_OPTS="-Xmx2g -Xms2g -Xmn1g -XX:PermSize=128M -XX:MaxPermSize=128M -XX:+DisableExplicitGC -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data1/yarn-logs/nm_dump.log -Dcom.sun.management.jmxremote -Xloggc:/data1/yarn-logs/nm_gc.log -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCApplicationConcurrentTime -XX:+PrintTenuringDistribution -XX:ErrorFile=/data1/yarn-logs/nm_err_pid"

后来经过分析,确实是代码处理有问题

containerMetric占用了大部分内存

后来社区有patch可以修复HADOOP-13362

解决方案

  • 1.关掉ContainerMetric,默认是开启的(yarn.nodemanager.container-metrics.enable默认true
    改为false)
  • 2.打patch

参考工具

IBM分析工具

[Hadoop问题] IOException: Got error, status message , ack with firstBadLink as xxx.xx.xx.xx:50010

关键日志:

2016-08-24T02:00:32.362 08:00] [ERROR] hadoop.hdfs.DFSClient.closeAllFilesBeingWritten(DFSClient.java 980) [Thread-0] : Failed to close inode 22083674
java.io.IOException: Got error, status message , ack with firstBadLink as xxx.xxx.xxx.xxx:50010
at org.apache.hadoop.hdfs.protocol.datatransfer.DataTransferProtoUtil.checkBlockOpStatus(DataTransferProtoUtil.java:140)
at org.apache.hadoop.hdfs.DFSOutputStream$DataStreamer.createBlockOutputStream(DFSOutputStream.java:1334)
at org.apache.hadoop.hdfs.DFSOutputStream$DataStreamer.nextBlockOutputStream(DFSOutputStream.java:1237)
at org.apache.hadoop.hdfs.DFSOutputStream

原因当时DN超过了每个磁盘预留的限制:

[2016-08-24T02:00:31.494+08:00] [INFO] server.datanode.DataNode.writeBlock(DataXceiver.java 837) [DataXceiver for client DFSClient_NONMAPREDUCE_103164656_1 at /172.16.183.26:29414 [Receiving block BP-964157621-172.16.172.17-1470393241028:blk_1094132102_20397583]] : opWriteBlock BP-964157621-172.16.172.17-1470393241028:blk_1094132102_20397583 received exception org.apache.hadoop.util.DiskChecker$DiskOutOfSpaceException: Out of space: The volume with the most available space (=123444224 B) is less than the block size (=134217728 B).

原因是balance的速度不够迅速,有一种的解决方案,但没测过,想法是每个盘可写最多不超出128M(预留为100G),即第一个满了可以写,但不能超过一个block的大小,这样目测可以避免这样的问题。

[HADOOP] 慢任务排查问题集合

1.某些任务因为一个task变慢导致整个job变慢

场景:

之前遇到有些任务的map执行很慢,然后发现在执行任务时读取某些文件变慢,但就是不知道慢在哪,这时我们可以在那台机器,打开debug日志

export HADOOP_ROOT_LOGGER=DEBUG,console

然后用hdfs dfs -get /path/to/yourFIle就可以详细的看到他是链接到哪台DN导致响应缓慢,然后就可以登陆机器排查改DN的网络是否流量过高,机器负载等相关信息

解决方案

把该DN临时停止,读取数据时连接到其他副本的DN

[Linux] 简单了解Linux的Page Cache

在Linux下,Page Cache可以加速访问磁盘上的文件,这是因为,当它第一次读或写数据到类似硬盘一样的存储介质时,Linux会存储这些数据到闲置的内存区域,它充当于一个缓存的角色,如果以后读取数据,他就可以迅速的在缓存中读取,这篇文章将会简单的让你了解有关Page Cache的一些信息。

内存使用

在Linux下,有多少内存被Page Cache使用,可以用free -m查看Cached那一列,例如:

➜  free -m
             total       used       free     shared    buffers     cached
Mem:          7684       7437        246        230        322        734
-/+ buffers/cache:       6380       1303
Swap:          255        255          0

数据写入

如果数据被写入,他首先会写到Page Cache,并把其作为一个脏页(dirty page)进行管理,“dirty”意味着数据存储在Page Cache中,但需要先写入到底层的存储设备,这些脏页的内容会被周期性的转移(系统调用sync或fsync)到底层的存储设备上。

下面的例子将会展示创建10M的文件,它首先将会写入到Page Cache中,相应的脏页将会增加,直到他把数据写到磁盘上,在这种情况下我们将会使用sync命令

➜  ~ cat /proc/meminfo | grep Dirty
Dirty:               160 kB
➜  ~ dd if=/dev/zero of=testfile.txt bs=1M count=10
记录了10+0 的读入
记录了10+0 的写出
10485760字节(10 MB)已复制,0.0157552 秒,666 MB/秒
➜  ~ cat /proc/meminfo | grep Dirty                
Dirty:             10480 kB
➜  ~ sync                                          
➜  ~ cat /proc/meminfo | grep Dirty
Dirty:               124 kB

数据读取

文件的写入操作不仅仅只有写入,也有读的操作,例如,当你读取同一个40M的文件两次,第二次读取将会变快,因为文件的block直接来自Page Cache的内存而不会去读取磁盘

➜  dumpdir free -m
             total       used       free     shared    buffers     cached
Mem:          7684       7491        192        243        328        667
-/+ buffers/cache:       6495       1188
Swap:          255        255          0
➜  dumpdir vim dump.dat
➜  dumpdir free -m
             total       used       free     shared    buffers     cached
Mem:          7684       7515        168        243        271        691
-/+ buffers/cache:       6552       1132
Swap:          255        255          0

如果Linux的application使用的可用内存不能够满足,长时间未被使用的Page Cache将会被删除