NameNode主备宕机引发的思考

大家都知道在双十一这些电商大型营销活动期间，电商网站的访问量等是平时的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的机率。

近期文章：