記一次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叢集調整,出現好幾次都抖動都沒有出現過上面的異常情況了。
雖然這次問題很低階,但是這一次的排查過程,還是可以參考,僅做筆記。
相關文章
- 測不準原理?記一次Guava佇列問題的排查Guava佇列
- 記一次排查CPU高的問題
- 關於生產系統鎖問題的排查
- 記一次生產問題的排查,讓我領略了演算法的重要性演算法
- 記一次oom問題排查OOM
- 記錄一次問題排查
- 記一次生產頻繁發生FullGC問題GC
- 記一次 Laravel MethodNotAllowedHttpException 問題排查LaravelHTTPException
- 記一次線上FGC問題排查GC
- 記一次線上崩潰問題的排查過程
- 記一次棧溢位異常問題的排查
- 記一次OOM問題排查過程OOM
- 一次生產環境OOM排查OOM
- 生產環境部署springcloud微服務啟動慢的問題排查SpringGCCloud微服務
- 記一次線上websocket返回400問題排查Web
- 記一次 MySQL 資料庫問題排查MySql資料庫
- 一次生產環境CPU佔用高的排查
- 一次容器MySQL的效能問題排查MySql
- 記一次協助排查許可權問題的經歷
- Arthas 實踐——生產環境排查 CPU 飈高問題
- 記一次 Kafka 重啟失敗問題排查Kafka
- 記一次線上報錯日誌問題排查
- OSSPostObject未發生回撥的問題排查Object
- Java記憶體溢位OutOfMemoryError的產生與排查Java記憶體溢位Error
- 線上問題排查:記一次 Redis Cluster Pipeline 導致的死鎖問題Redis
- 排查Java的記憶體問題Java記憶體
- 記一次安卓手機水印顯示問題的排查歷程安卓
- 一次線上問題的排查解決過程
- 一次線上CPU高的問題排查實踐
- 一次線上問題排查所引發的思考
- 新舊系統更替產生的資料遷移問題
- 週末生產事故!一次心驚肉跳的伺服器入侵排查....伺服器
- 記錄一次詭異的拼接sql不生效問題SQL
- 一次快取效能問題排查快取
- 【問題排查篇】一次業務問題對 ES 的 cardinality 原理探究
- 記一次記憶體溢位問題的排查、分析過程及解決思路記憶體溢位
- 一次ygc越來越慢的問題排查過程GC
- 記一次hadoop yarn環境無法提交任務的問題排查HadoopYarn