表述

在一次服務(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)存泄漏問題，在啟動(dòng)腳本中加入 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=D:heapdump.log，第二天起來一看還是掛了沒有出現(xiàn)dump日志說明不是內(nèi)存泄漏

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

3、服務(wù)準(zhǔn)時(shí)0點(diǎn)3秒掛，后續(xù)我寫了個(gè)腳本加入執(zhí)行計(jì)劃每日凌晨1點(diǎn)檢查服務(wù)并啟動(dòng)，發(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ù)的啟動(dòng)腳本加入到執(zhí)行計(jì)劃中每日凌晨檢查并啟動(dòng)，沒有找到好的解決方案也不知道是什么問題，希望知道的大佬告知一下感激不盡。

附上執(zhí)行計(jì)劃?rùn)z查腳本

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

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

最終解決

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

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

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

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

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

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

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

補(bǔ)充知識(shí)：Springboot啟動(dòng)即掛掉問題

提示說明端口8080被占用

將端口改為其他端口號(hào)即可

以上這篇記一次springboot服務(wù)凌晨無故宕機(jī)問題的解決就是小編分享給大家的全部?jī)?nèi)容了，希望能給大家一個(gè)參考，也希望大家多多支持好吧啦網(wǎng)。