NameNode主备宕机引发的思考-阿里云开发者社区

开发者社区> 大数据> 正文

NameNode主备宕机引发的思考

简介: 大家都知道在双十一这些电商大型营销活动期间,电商网站的访问量等是平时的N倍。每当这个时候到来,无论是开发还是运维人员都严阵以待生怕服务出现问题。很不幸,笔者的一个朋友在一家电商公司上班,在双十一时,恰恰就出现了NameNode宕机的生产事故。 鉴于涉及到一些公司私密信息,不便发一些排查问题截图,同时,JVM调优作为大数据从业者必备技能,笔者打算后续分篇系统阐述,这里仅就问题现象、问题分析、解决方案三个层面阐述这次生产事故从产生、排查到最终解决的历程。希望能给大家带来一定思考,避免此类事情的发生以及提供出现类似问题时处理的一个思路。

大家都知道在双十一这些电商大型营销活动期间,电商网站的访问量等是平时的N倍。每当这个时候到来,无论是开发还是运维人员都严阵以待生怕服务出现问题。很不幸,笔者的一个朋友在一家电商公司上班,在双十一时,恰恰就出现了NameNode宕机的生产事故。

鉴于涉及到一些公司私密信息,不便发一些排查问题截图,同时,JVM调优作为大数据从业者必备技能,笔者打算后续分篇系统阐述,这里仅就问题现象、问题分析、解决方案三个层面阐述这次生产事故从产生、排查到最终解决的历程。希望能给大家带来一定思考,避免此类事情的发生以及提供出现类似问题时处理的一个思路。

问题现象

电商节日,各种促销活动等导致网站访问量等激增,数据量比平时多了很多倍,然后NameNode主备都挂了!问题排查的时候发现有大量的full GC日志

问题分析

NameNode的主要职责就是管理元数据,不会频繁创建和销毁对象,官方推荐1/4--1/3给年轻代,剩下的给老年代。当然这个配比应对平时的数据量是没有问题的,但在这种大型营销活动盛行的时候,网站访问量激增带来的是数据量激增,那么NameNode需要管理的元数据也会激增,对NameNode的内存是一个很大挑战。

  1. 正常情况下,对象创建最初在新生代Eden区,Eden区放满,进行minor GC到Survivor区,反复进行minor GC,当Survivor对象年龄达到默认"15"岁,存活的对象进入老年区
  2. Namenode启动时加载元数据到堆内存,元数据一般不会改变,会一直加载到老年代,当日新增数据量特别大时,NameNode加载大量数据到老年代,然后当老年代空间不足发生full GC,日志持续剧增,导致频繁发生full GC,最终主NameNode宕掉。然后备NameNode上,同样因为频繁发生full GC最终宕掉。

解决方案

方案1:调整NameNode新生代和老年代空间大小,将年轻代空间调小一些,老年代相应调大一些。新生代和老年代比例参数:-XX:NewRatio。
(如内存分配给新生代和老年代内存总共15G,按照官方说法分配给新生代5G,老年代10G,但假如实际情况是新生代根本用不了这么多,1G左右就够用。则可分配给新生代2G,老年代13G即可)

方案2:加内存(差方案,毕竟内存有限,增加服务器配置如内存是要走申请的。。还是要解决根本问题才是王道)

最终结果

1.问题解决

2.笔者的朋友当月的鸡腿没了。。
对于NameNode主要管理元数据,而元数据一般不会频繁发生变化,可以适当将新生代比例设置小点,老年代比例设置大点。但是像Hive、Spark等任务型的,经常会频繁的创建和销毁对象,这个时候就可以把新生代比例设置大点,老年代比例设置小点以避免发生full GC的机率。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
大数据
使用钉钉扫一扫加入圈子
+ 订阅

大数据计算实践乐园,近距离学习前沿技术

其他文章