hadoop配置 - Datanode GC优化一则
2013-10-31 14:44
148 查看
故障描述:
前一阵发现Jobtracker服务器宕机,追查宕机前系统负载情况,发现很多线程被阻塞,大多上面一些cron job对hdfs目录请求响应时间较长导致的,进一步追查后发现有若干datanode被exclude掉,报错信息如下:
datanode报错
仔细排查所有ERROR,发现在datanode exclude后,之前部署的metric统计脚本发现,部分datanode内存耗尽,推测datanode节点存在内存瓶颈。
java.lang.OutOfMemoryError: Java heap space
2012-09-12 04:37:38,311 ERROR org.mortbay.log: Error for /metrics
之前线上hadoop集群遇到过几次大量由于Datanode内存溢出,被强制下线后,导致线上集群不稳定的情况,故针对如上内存问题进行JVM GC的优化:
1.原FGC影响时间较长:
优化前:
2.原Old Generation占用内存量巨大,可能产生内存溢出危险:
之后再不存在Datanode由于GC缓慢导致RPC超时引发的一连串问题。
总结:
优化最重要花最长时间的是定位问题,所以帮助快速定位问题的工具很重要,ganglia及datanode、jobtracker 日志都给了我很大帮助,本次主要优化思路是在保证GC影响时间较短情况下,让Old Generation提早进行FGC,来保证有足够内存容量应对突发内存请求,详细参数如下:
前一阵发现Jobtracker服务器宕机,追查宕机前系统负载情况,发现很多线程被阻塞,大多上面一些cron job对hdfs目录请求响应时间较长导致的,进一步追查后发现有若干datanode被exclude掉,报错信息如下:
datanode报错
ERROR1 ERROR org.apache.hadoop.hdfs.server.datanode.DataNode: DatanodeRegistration(x.x.x.x:50010, storageID=DS-1 437963415-x.x.x.x-50010-1331795684559, infoPort=50075, ipcPort=50020):DataXceiver java.net.ConnectException: Connection refused ERROR2 ERROR org.apache.hadoop.hdfs.server.datanode.DataNode: DatanodeRegistration(x.x.x.x:50010, storageID=DS-1 437963415-x.x.x.x-50010-1331795684559, infoPort=50075, ipcPort=50020):DataXceiver java.io.IOException: Connection reset by peer ERROR3 ERROR org.apache.hadoop.hdfs.server.datanode.DataNode: DatanodeRegistration(x.x.x.x:50010, storageID=DS-5 34013790-x.x.x.x-50010-1331795710872, infoPort=50075, ipcPort=50020):DataXceiver java.io.IOException: Interrupted receiveBlock ERROR4 ERROR org.apache.hadoop.hdfs.server.datanode.DataNode: DatanodeRegistration(x.x.x.x:50010, storageID=DS-3 46899942-x.x.x.x-50010-1331795684322, infoPort=50075, ipcPort=50020):DataXceiver java.io.EOFException: while trying to read 65557 bytes at org.apache.hadoop.hdfs.server.datanode.BlockReceiver.readToBuf(BlockReceiver.java:290) at org.apache.hadoop.hdfs.server.datanode.BlockReceiver.readNextPacket(BlockReceiver.java:334) at org.apache.hadoop.hdfs.server.datanode.BlockReceiver.receivePacket(BlockReceiver.java:398) at org.apache.hadoop.hdfs.server.datanode.BlockReceiver.receiveBlock(BlockReceiver.java:577) at org.apache.hadoop.hdfs.server.datanode.DataXceiver.writeBlock(DataXceiver.java:480) at org.apache.hadoop.hdfs.server.datanode.DataXceiver.run(DataXceiver.java:171)
仔细排查所有ERROR,发现在datanode exclude后,之前部署的metric统计脚本发现,部分datanode内存耗尽,推测datanode节点存在内存瓶颈。
java.lang.OutOfMemoryError: Java heap space
2012-09-12 04:37:38,311 ERROR org.mortbay.log: Error for /metrics
之前线上hadoop集群遇到过几次大量由于Datanode内存溢出,被强制下线后,导致线上集群不稳定的情况,故针对如上内存问题进行JVM GC的优化:
1.原FGC影响时间较长:
优化前:
S0 S1 E O P YGC YGCT FGC FGCT GCT 0.00 96.36 60.06 89.27 87.69 1926 387.419 93 589.308 976.728 0.00 96.36 60.07 89.27 87.69 1926 387.419 93 589.308 976.728 0.00 96.36 60.07 89.27 87.69 1926 387.419 93 589.308 976.728 0.00 96.36 60.18 89.27 87.69 1926 387.419 93 589.308 976.728 0.00 96.36 60.18 89.27 87.69 1926 387.419 93 589.308 976.728 优化后: 41.12 0.00 2.57 79.72 59.78 302 209.850 146 49.716 259.566 41.12 0.00 3.88 79.72 59.78 302 209.850 146 49.716 259.566 41.12 0.00 4.18 79.72 59.78 302 209.850 146 49.716 259.566 41.12 0.00 4.39 79.72 59.78 302 209.850 146 49.716 259.566 41.12 0.00 4.72 79.72 59.78 302 209.850 146 49.716 259.566平均影响时间从6.33ms降至0.34ms
2.原Old Generation占用内存量巨大,可能产生内存溢出危险:
优化前 PS Old Generation capacity = 2863333376 (2730.6875MB) used = 2556763896 (2438.3200607299805MB) free = 306569480 (292.36743927001953MB) 89.29326628294085% used 优化后: PS Old Generation capacity = 3221225472 (3072.0MB) used = 2118978904 (2020.8157577514648MB) free = 1102246568 (1051.1842422485352MB) 65.78176294763882% used占用比例从 89%->65%
之后再不存在Datanode由于GC缓慢导致RPC超时引发的一连串问题。
总结:
优化最重要花最长时间的是定位问题,所以帮助快速定位问题的工具很重要,ganglia及datanode、jobtracker 日志都给了我很大帮助,本次主要优化思路是在保证GC影响时间较短情况下,让Old Generation提早进行FGC,来保证有足够内存容量应对突发内存请求,详细参数如下:
export HADOOP_DATANODE_OPTS=”-server -XX:+UseConcMarkSweepGC -XX:SurvivorRatio=3 -XX:MaxTenuringThreshold=20 -XX:CMSInitiatingOccupancyFraction=80 -XX:+ExplicitGCInvokesConcurrent -XX:+PrintGCDateStamps -XX:+PrintTenuringDistribution -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCApplicationConcurrentTime ${HADOOP_DATANODE_OPTS}”
相关文章推荐
- hadoop大集群优化配置,datanode节点数量为100
- hadoop配置新节点后,出现 org.apache.hadoop.hdfs.server.datanode.DataNode: java.io.IOException: Incompatible n
- hadoop配置好之后启服务,jps能看到datanode进程,可是后台的datanode日志有如下错误,且50070端口上也是没有活的节点
- hadoop集群的负载均衡配置与添加DataNode节点和TaskTracker节点
- hadoop1.x配置 - 集群增加datanode
- Ubuntu 14.04下hadoop 2.2.0 伪分布环境配置datanode不能启动的解决办法
- Hadoop2.6 datanode配置在线更新
- 解决更改hadoop核心配置文件后会出现DataNode,或者NameNode无法启动的问题
- hadoop集群配置datanode无法启动的原因
- hadoop集群配置datanode无法启动的原因
- hadoop1.x配置 - 集群删除datanode
- 关于配置伪分布hadoop无法启动datanode的解决
- hadoop配置完成后datanode没有启动
- Hadoop配置datanode无法连接到master
- hadoop配置好之后启服务,jps能看到datanode进程,可是后台的datanode日志有如下错误,且50070端口上也是没有活的节点
- 复制hadoop配置文件到datanode的脚本
- 在集群上安装Hadoop1.2.1,并配置好,启动hdfs后使用jps查看datanode,启动后过一会再看就消失了
- Hadoop 2.2.0 在Red Hat Enterprise Linux 6.1 上的分布式配置(VMware虚拟机,1个namenode,2个datanode)
- hadoop-HA集群搭建,启动DataNode,检测启动状态,执行HDFS命令,启动YARN,HDFS权限配置,C++客户端编程,常见错误
- hadoop dfs.datanode.du.reserved 预留空间配置方法