記一次SparkStreaming不產生新的batchJob的問題排查

現象描述 ：

streming ui介面看不到新提交的bath ，系統沒有任何輸出

比如時間已經是18:40多了,但是處理的batchtime 還是18:21,

排查過程：

首先 隨機檢視幾個container的日誌 沒有發現明顯異常
其次 檢視資料量監控，發現最後一個batch的的資料量明顯有很大的增長
斷定肯定是和這次的資料量增長有關。
然後 懷疑和driver機器有關係，然後登陸driver 機器，檢視磁碟讀寫延遲以及佇列，發現正常， 檢視cpu使用情況，發現正常，在檢視記憶體使用情況，剩餘空間還很大。
然後 檢視driver的程式，發現cpu和記憶體使用率都不高
然後 jstack -l 執行緒id ，檢視一下，提示沒有死鎖
然後列印gc情況，發現fgc的次數極其頻繁，看來和gc有關係。為了不影響線上資料產出，先想調大記憶體。於是修改spark.yarn.driver.memory的記憶體（以前是2G），改成4G,然後重啟job。
結果幾天後資料量又出現抖動，檢視了一下還是顯示有gc的次數很多，而且時間比較長。因為我這程式碼比較簡單。資料量雖然大，但是driver應該用不了6g啊
於是檢視driver的程式,ps -ef|grep 000001(driver 的conainer 的id都是這個結尾)
仔細看了一下 居然發現-Xmx1024m ,之前不是配置成6g了麼，看來沒有生效。於是用jmap在看一下jmap -heap 執行緒id ，看了一下，堆記憶體使用新生代 99%，s097%,perm 96%，
看來是記憶體的問題，於是仔細檢查配置引數，沒發現問題。於是檢視spark的原始碼

這才發現配置項的名稱是 spark.driver.memory 不是spark.yarn.driver.memory
於是趕緊修改了，重啟一下，然後再看-Xmx已經恢復。

最後這幾天正好趕上kafka叢集調整，出現好幾次都抖動都沒有出現過上面的異常情況了。
雖然這次問題很低階，但是這一次的排查過程，還是可以參考，僅做筆記。