快捷導(dǎo)航

記一次springboot服務(wù)凌晨無故宕機(jī)問題的解決

更新時間：2020年09月17日 09:50:16 作者：蠟筆小興灬

這篇文章主要介紹了記一次springboot服務(wù)凌晨無故宕機(jī)問題的解決，具有很好的參考價值，希望對大家有所幫助。一起跟隨小編過來看看吧

表述

在一次服務(wù)更新后發(fā)現(xiàn)每天凌晨0點(diǎn)3秒服務(wù)準(zhǔn)時掛，開始的時候認(rèn)為是maven依賴中存在system.exit(3)類似這樣的代碼，但是我想了下這個代碼很多客戶都有用到但是只有這一個客戶出現(xiàn)了問題，而且另外一個服務(wù)沒有更新在此前幾個月都是沒問題的這幾天也是一樣無故掛了。

環(huán)境

windows服務(wù)器

排查

1、初步懷疑是內(nèi)存泄漏問題，在啟動腳本中加入 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=D:\heapdump.log，第二天起來一看還是掛了沒有出現(xiàn)dump日志說明不是內(nèi)存泄漏

2、白天幾千幾萬的請求量都沒有掛，凌晨時候星星兩兩的請求量甚至沒有請求卻掛了

3、服務(wù)準(zhǔn)時0點(diǎn)3秒掛，后續(xù)我寫了個腳本加入執(zhí)行計劃每日凌晨1點(diǎn)檢查服務(wù)并啟動，發(fā)現(xiàn)有寫腳本的服務(wù)還是0點(diǎn)3秒掛而另外一個服務(wù)變成1點(diǎn)10幾分左右掛了

4、有懷疑可能是logback的問題，日志生成規(guī)則是按日期備份的，可是每個客戶都是這樣的配置就這個客戶有問題所以暫時排除這個可能了

臨時解決

1、暫時給幾個服務(wù)的啟動腳本加入到執(zhí)行計劃中每日凌晨檢查并啟動，沒有找到好的解決方案也不知道是什么問題，希望知道的大佬告知一下感激不盡。

附上執(zhí)行計劃檢查腳本

@echo off
echo 正在檢測啟動服務(wù)…請不要關(guān)閉該窗口
D:
cd “D:\寫上服務(wù)的目錄”
:ks
set num=0
for /f %%i in (‘netstat -ano^| find “:服務(wù)的端口”') do set /a num=%num%+1
echo %num%
if %num% == 0 (
echo “開始啟動服務(wù)”
call D:\aaa.bat
) else (
echo “無需啟動服務(wù)”
)

其中D:\aaa.bat 是服務(wù)的啟動腳本這里也可以直接寫上java -jar springboot服務(wù).jar類似這樣的代碼

最終解決

經(jīng)昨晚12點(diǎn)時候錄屏服務(wù)器后看后終于找到了問題所在，控制臺沒有絲毫的報錯信息直接程序崩潰，這就是windows服務(wù)器的不足之處，如果此時服務(wù)器是Linux的話會在項(xiàng)目目錄底下記錄崩潰的Jvm日志。思考之后發(fā)現(xiàn)果真竟然是logback的鍋，找到原因：

1、因?yàn)閘ogback配置中沒有加入maxFileSize的配置，導(dǎo)致日志文件大小有幾個G

2、服務(wù)器本身性能配置一般

3、logback采用的是zip壓縮按日備份的

4、壓縮文件是很耗CPU的，文件越大CPU占用越多，如果文件很大就會導(dǎo)致壓縮到一半程序崩潰，這里就是出現(xiàn)了這種情況導(dǎo)致壓縮到一半沒成功，tmp臨時文件也沒有被刪除

5、沒有出現(xiàn)該問題的幾個客戶是因?yàn)槿罩疚募紱]有達(dá)到這種級別的量，其次其他幾個客戶的服務(wù)器性能都是很OK的

解決方法就是在加入maxFileSize配置建議值是128M。值越大對服務(wù)器的性能要求就越高，我這邊因?yàn)榉?wù)器性能一般保險起見設(shè)置128M

補(bǔ)充知識：Springboot啟動即掛掉問題