大家都知道在雙十一這些電商大型營銷活動期間，電商網站的訪問量等是平時的N倍。每當這個時候到來，無論是開發還是運維人員都嚴陣以待生怕服務出現問題。很不幸，筆者的一個朋友在一家電商公司上班，在雙十一時，恰恰就出現了NameNode宕機的生產事故。
鑑於涉及到一些公司私密信息，不便發一些排查問題截圖，同時，JVM調優作為大數據從業者必備技能，筆者打算後續分篇系統闡述，這裡僅就問題現象、問題分析、解決方案三個層面闡述這次生產事故從產生、排查到最終解決的歷程。希望能給大家帶來一定思考，避免此類事情的發生以及提供出現類似問題時處理的一個思路。
問題現象
電商節日，各種促銷活動等導致網站訪問量等激增，數據量比平時多了很多倍，然後NameNode主備都掛了！問題排查的時候發現有大量的full GC日誌
問題分析
NameNode的主要職責就是管理元數據，不會頻繁創建和銷燬對象，官方推薦1/4--1/3給年輕代，剩下的給老年代。當然這個配比應對平時的數據量是沒有問題的，但在這種大型營銷活動盛行的時候，網站訪問量激增帶來的是數據量激增，那麼NameNode需要管理的元數據也會激增，對NameNode的內存是一個很大挑戰。
- 正常情況下，對象創建最初在新生代Eden區，Eden區放滿，進行minor GC到Survivor區，反覆進行minor GC，當Survivor對象年齡達到默認"15"歲，存活的對象進入老年區
- 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的機率。