背景
某局點(diǎn)上線新版本后幻枉,實(shí)時(shí)標(biāo)注(spark streaming任務(wù))運(yùn)行一個(gè)小時(shí)后诡蜓,任務(wù)卡死。
具體情況:實(shí)時(shí)數(shù)據(jù)量10w/s, 任務(wù)配置 executor 60個(gè)蔓罚, 內(nèi)存10g椿肩,到一個(gè)小時(shí)任務(wù)開(kāi)始積壓
定位過(guò)程
- 對(duì)比任務(wù)和之前版本的配置豺谈,變化不大,理論上不應(yīng)該是配置導(dǎo)致積壓
- 初步懷疑新加的字符串替換方法影響性能核无,經(jīng)過(guò)構(gòu)造數(shù)據(jù)測(cè)試發(fā)現(xiàn)非瓶頸
- 每次都到一個(gè)小時(shí)就開(kāi)始積壓,懷疑是full GC導(dǎo)致团南,gc日志顯示spark確實(shí)每隔一段時(shí)間會(huì)人為調(diào)用System.gc炼彪,但是full GC的時(shí)間較短吐根,僅為300ms左右
- 準(zhǔn)備到executor節(jié)點(diǎn)打jstack辐马,平時(shí)沒(méi)多留意拷橘,yarn前臺(tái)可以看到每個(gè)節(jié)點(diǎn)的thread dump(可以多次進(jìn)入查看喜爷,搜索main或者com.xxx),較多executor節(jié)點(diǎn)線程出現(xiàn)在某個(gè)讀取hdfs文件的方法(這部分代碼為新增邏輯)檩帐,這個(gè)方法剛好一個(gè)小時(shí)調(diào)度一次,由于executor較多湃密,同時(shí)讀取name node壓力太大四敞,導(dǎo)致瞬間卡頓,刪除拔妥,一切正常了。