快捷導(dǎo)航

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

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

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

表述

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

環(huán)境

windows服務(wù)器

排查

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

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

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

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

臨時(shí)解決

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

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

@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)時(shí)候錄屏服務(wù)器后看后終于找到了問題所在，控制臺沒有絲毫的報(bào)錯(cuò)信息直接程序崩潰，這就是windows服務(wù)器的不足之處，如果此時(shí)服務(wù)器是Linux的話會在項(xiàng)目目錄底下記錄崩潰的Jvm日志。思考之后發(fā)現(xiàn)果真竟然是logback的鍋，找到原因：

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

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

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

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

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

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

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