轉載請註明出處：http://blog.csdn.net/gklifg/article/details/50418109
剛剛從java組轉崗找數據組，學習大數據的知識，開發語言也從java轉到python新奇之外也遇到了諸多問題，其中最令我頭疼的就是在hive上的統計任務總是三天兩頭地報告OutOfMemory一開始因爲有別的同事的任務干擾，我以爲是計算資源不夠導致的，但後來把任務轉移到了另一個集羣后，問題仍然存在，讓我百思不得其解。
問題的具體描述如下：
統計邏輯使用python pyhs2連接hive，執行HQL查詢。單獨執行時都很順利，定時執行時，基本上4天中必有一天會掛掉，報OutOfMemory: Java heap space，這時候一般會重啓hiveServer2，於是各個問題就又不見了，直到下一個4天。
現在看起來一切都很清晰，但是當身處問題之中的時候，很多噪音是會擾亂視線，比如說不定期的其他任務(spark、mapreduce)插入，因爲其他問題引起的其他同事手動重啓hiveServer2，這些都會擾亂整個問題的外在表現形式。以至於很難看出內存溢出是有一個明顯的週期的。
由於是OutOfMemory，想來想去也沒什麼好的辦法，只能監控一下jvm，看看那時候到底發生了什麼。不知什麼問題在AWS上沒法使用jmap -heap，無奈就先使用jstat
監控語句如下：
jstat -gcutil [進程號] 5000 --每5秒打印一次jvm各個內存區的狀態另外找了一個監控系統內存的語句：
vmstat | sed -n '/[0-9]/p'設定兩個語句將結果輸出到文件裏後就開始等待問題出現，因爲本人也是現學現賣，對於jvm的瞭解非常淺，當時發現jvm的永久代空間很開變成近100%，但不知道是不是有問題。
過了一個週末，HIVE果然還是掛了，查日誌的時候發現當時的jvm內存是這樣的：
S0 S1 E O P YGC YGCT FGC FGCT GCT
0.00 0.00 100.00 100.00 99.37 14086 39.094 13348 5176.146 5215.240
0.00 0.00 100.00 100.00 99.37 14086 39.094 13348 5176.146 5215.240
0.00 0.00 100.00 100.00 99.37 14086 39.094 13348 5176.146 5215.240
0.00 0.00 100.00 100.00 99.37 14086 39.094 13348 5176.146 5215.240
0.00 0.00 100.00 100.00 99.37 14086 39.094 13348 5176.146 5215.240
0.00 0.00 100.00 100.00 99.37 14086 39.094 13348 5176.146 5215.240
0.00 0.00 100.00 100.00 99.37 14086 39.094 13349 5176.532 5215.626
0.00 0.00 100.00 100.00 99.37 14086 39.094 13349 5176.532 5215.626
0.00 0.00 100.00 100.00 99.37 14086 39.094 13349 5176.532 5215.626
0.00 0.00 100.00 100.00 99.37 14086 39.094 13349 5176.532 5215.626
可以看到新生代和老年代都已經爆滿，永久代幾乎爆滿，jvm一直在做full GC，但是沒有效果，各個內存區都被佔用了。這種情況發生後同事直接重啓了hiveServer2，我沒有來的及查看一下當時堆中的對象信息，不知道有沒有什麼有價值的信息在裏面。就現在的日誌來看，我發現老年代和持久代的內存只要上去了，就再沒有下降過，而當這兩塊區域飽和後，新生代也出現了這種現象。這時候忽然意識到，是有什麼資源沒釋放吧！？
一看代碼，果然，有兩個腳本pyhs2的連接沒有關閉！
java裏面連接都是框架管理的，平時沒管過，換到python來，忽視了這個重要的步驟，血的教訓啊，連接一定要關閉！另外總的來說這次問題的原因雖然相當低級，但是排查用到的手段和思維方式給了我很多收穫，自責的同時也有戰勝困難的喜悅，記錄下來，自勉。