一個(gè)線上服務(wù)OOM的問題分享

前言

前一段時(shí)間，公司同事的一個(gè)線上服務(wù)OOM的問題，我覺得挺有意思的，在這里跟大家一起分享一下。

我當(dāng)時(shí)其實(shí)也參與了一部分問題的定位。

基于 Spring Boot + MyBatis Plus + Vue & Element 實(shí)現(xiàn)的后臺(tái)管理系統(tǒng) + 用戶小程序，支持 RBAC 動(dòng)態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

項(xiàng)目地址：https://gitee.com/zhijiantianya/ruoyi-vue-pro

視頻教程：https://doc.iocoder.cn/video/

1 案發(fā)現(xiàn)場(chǎng)

他們有個(gè)mq消費(fèi)者服務(wù)，在某一天下午，出現(xiàn)OOM了，導(dǎo)致服務(wù)直接掛掉。

當(dāng)時(shí)我們收到了很多內(nèi)存的報(bào)警郵件。

發(fā)現(xiàn)問題之后，運(yùn)維第一時(shí)間，幫他們dump了當(dāng)時(shí)的內(nèi)存快照，以便于開發(fā)人員好定位問題。

之后，運(yùn)維重啟了該服務(wù)，系統(tǒng)暫時(shí)恢復(fù)了正常。

大家都知道，如果出現(xiàn)了線上OOM問題，為了不影響用戶的正常使用，最快的解決辦法就是重啟服務(wù)。

但重啟服務(wù)治標(biāo)不治本，只能臨時(shí)解決一下問題，如果不找到真正的原因，難免下次在某個(gè)不經(jīng)意的時(shí)間點(diǎn)，又會(huì)出現(xiàn)OOM問題。

所以，有必要定位一下具體原因。

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 實(shí)現(xiàn)的后臺(tái)管理系統(tǒng) + 用戶小程序，支持 RBAC 動(dòng)態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

項(xiàng)目地址：https://gitee.com/zhijiantianya/yudao-cloud

視頻教程：https://doc.iocoder.cn/video/

2 初步定位問題

當(dāng)時(shí)運(yùn)維dump下來(lái)的內(nèi)存快照文件有3G多，太大了，由于公司內(nèi)網(wǎng)限制，沒辦法及時(shí)給到開發(fā)這邊。

沒辦法，只能先從日志文件下手了。

在查日志之前，我們先查看了prometheus上的服務(wù)監(jiān)控。查到了當(dāng)時(shí)那個(gè)mq消費(fèi)者服務(wù)的內(nèi)存使用情況，該服務(wù)的內(nèi)存使用率一直都比較平穩(wěn)，從2022-09-26 1429開始，出現(xiàn)了一個(gè)明顯的內(nèi)存飆升情況。

根據(jù)以往經(jīng)驗(yàn)總結(jié)出來(lái)的，在追查日志時(shí)，時(shí)間點(diǎn)是一個(gè)非常重要的過(guò)濾條件。

所以，我們當(dāng)時(shí)重點(diǎn)排查了2022-09-26 1429前后5秒鐘的日志。

由于這個(gè)服務(wù)，并發(fā)量不大，在那段時(shí)間的日志量并不多。

所以，我們很快就鎖定了excel文件導(dǎo)入導(dǎo)出功能。

該功能的流程圖如下：

用戶通過(guò)瀏覽器上傳excel，調(diào)用文件上傳接口。

該接口會(huì)上傳excel到文件服務(wù)器。然后將文件url，通過(guò)mq消息，發(fā)送到mq服務(wù)器。

mq消費(fèi)者消費(fèi)mq消息，從文件服務(wù)器中獲取excel數(shù)據(jù)，做業(yè)務(wù)處理，然后把結(jié)果寫入新的excel中。

mq消費(fèi)者將新excel文件上傳到文件服務(wù)器，然后發(fā)websocket消息通知用戶。

用戶收到通知結(jié)果，然后可以下載新的excel。

經(jīng)過(guò)日志分析，時(shí)間點(diǎn)剛好吻合，從excel文件導(dǎo)入之后，mq消費(fèi)者服務(wù)的內(nèi)存使用率一下子飆升。

3. 打不開dump文件

從上面分析我們得出初步的結(jié)論，線上mq消費(fèi)者服務(wù)的OOM問題，是由于excel導(dǎo)入導(dǎo)出導(dǎo)致的。

于是，我們查看了相關(guān)excel文件導(dǎo)入導(dǎo)出代碼，并沒有發(fā)現(xiàn)明顯的異常。

為了找到根本原因，我們不得不把內(nèi)存快照解析出來(lái)。

此時(shí)，運(yùn)維把內(nèi)存快照已經(jīng)想辦法發(fā)給了相關(guān)的開發(fā)人員（我的同事）。

那位同事用電腦上安裝的內(nèi)存分析工具：MAT（Memory Analyzer Tool），準(zhǔn)備打開那個(gè)內(nèi)存快照文件。

但由于該文件太大，占了3G多的內(nèi)存，直接打開失敗了。

MemoryAnalyzer.ini文件默認(rèn)支持打開的內(nèi)存文件是1G，后來(lái)它將參數(shù)-xmx修改為4096m。

修改之后，文件可以打開了，但打開的內(nèi)容卻有問題。

猛然發(fā)現(xiàn)，原來(lái)是JDK版本不匹配導(dǎo)致的。

他用的MAT工具是基于SunJDK，而我們生成環(huán)境用的OpenJDK，二者有些差異。

SunJDK采用JRL協(xié)議發(fā)布，而OpenJDK則采用GPL V2協(xié)議發(fā)布。兩個(gè)協(xié)議雖然都是開放源代碼的，但是在使用上的不同，GPL V2允許在商業(yè)上使用，而JRL只允許個(gè)人研究使用。

所以需要下載一個(gè)基于OpenJDK版本的MAT內(nèi)存分析工具。

4. 進(jìn)一步分析

剛好，另一個(gè)同事的電腦上下載過(guò)OpenJDK版本的MAT內(nèi)存分析工具。

把文件發(fā)給他幫忙分析了一下。

最后發(fā)現(xiàn)org.apache.poi.xssf.usermodel.XSSFSheet類的對(duì)象占用的內(nèi)存是最多的。

目前excel的導(dǎo)入導(dǎo)出功能，大部分是基于apache的POI技術(shù)，而POI給我們提供了WorkBook接口。

常用的WorkBook接口實(shí)現(xiàn)有三種：

HSSFWorkbook：它是早期使用最多的工具，支持Excel2003以前的版本，Excel的擴(kuò)展名是.xls。只能導(dǎo)出65535條數(shù)據(jù)，如果超過(guò)最大記錄條數(shù)會(huì)報(bào)錯(cuò)，但不會(huì)出現(xiàn)內(nèi)存溢出。

XSSFWorkbook：它可以操作Excel2003-Excel2007之間的版本，Excel的擴(kuò)展名是.xlsx。最多可以導(dǎo)出104w條數(shù)據(jù)，會(huì)創(chuàng)建大量的對(duì)象存放到內(nèi)存中，可能會(huì)導(dǎo)致內(nèi)存溢出。

SXSSFWorkbook：它可以操作Excel2007之后的所有版本，Excel的擴(kuò)展名是.xlsx。SXSSFWorkbook是streaming版本的XSSFWorkbook，它只會(huì)保存最新的rows在內(nèi)存里供查看，以前的rows都會(huì)被寫入到硬盤里。用磁盤空間換內(nèi)存空間，不會(huì)導(dǎo)致內(nèi)存溢出。

看到了這個(gè)類，可以驗(yàn)證之前我們通過(guò)日志分析問題，得出excel導(dǎo)入導(dǎo)出功能引起OOM的結(jié)論，是正確的。

那個(gè)引起OOM問題的功能，剛好使用了XSSFWorkbook處理excel，一次性創(chuàng)建了大量的對(duì)象。

關(guān)鍵代碼如下：

XSSFWorkbookwb=newXSSFWorkbook(newFileInputStream(file));
XSSFSheetsheet=wb.getSheetAt(0);

我們通過(guò)MAT內(nèi)存分析工具，已經(jīng)確定OOM問題的原因了。接下來(lái)，最關(guān)鍵的一點(diǎn)是：如何解決這個(gè)問題呢？

5. 如何解決問題？

根據(jù)我們上面的分析，既然XSSFWorkbook在導(dǎo)入導(dǎo)出大excel文件時(shí)，會(huì)導(dǎo)致內(nèi)存溢出。那么，我們改成SXSSFWorkbook不就行了？

關(guān)鍵代碼改動(dòng)如下：

XSSFWorkbookwb=newXSSFWorkbook(newFileInputStream(file));
SXSSFWorkbookswb=newSXSSFWorkbook(wb,100);
SXSSFSheetsheet=(SXSSFSheet)swb.createSheet("sheet1");

使用SXSSFWorkbook將XSSFWorkbook封裝了一層，其中100表示excel一次讀入內(nèi)存的最大記錄條數(shù)，excel中其余的數(shù)據(jù)將會(huì)生成臨時(shí)文件保存到磁盤上。這個(gè)參數(shù)，可以根據(jù)實(shí)際需要調(diào)整。

還有一點(diǎn)非常重要：

sheet.flushRows();

需要在程序的結(jié)尾處加上上面的這段代碼，不然生成的臨時(shí)文件是空的。

這樣調(diào)整之后，問題被暫時(shí)解決了。

此外，順便說(shuō)一句，在使用WorkBook接口的相關(guān)實(shí)現(xiàn)類時(shí)，用完之后，要記得調(diào)用close方法及時(shí)關(guān)閉喔，不然也可能會(huì)出現(xiàn)OOM問題。

6. 后續(xù)思考

其實(shí)，當(dāng)時(shí)我建議過(guò)使用阿里開源的EasyExcel解決OOM的問題。

但同事說(shuō)，excel中有很多樣式，在導(dǎo)出的新excel中要保留之前的樣式，同時(shí)增加一列，返回導(dǎo)入的結(jié)果。

如果使用EasyExcel不太好處理，使用原始的Workbook更好處理一些。

但是使用mq異步導(dǎo)入excel文件這套方案，如果并發(fā)量大的話，任然可能會(huì)出現(xiàn)OOM問題，有安全隱患。

因此，有必要調(diào)整一下mq消費(fèi)者。

后來(lái)，mq消費(fèi)者的線程池，設(shè)置成4個(gè)線程消費(fèi)，避免消費(fèi)者同時(shí)處理過(guò)多的消息，讀取大量的excel，導(dǎo)致內(nèi)存占用過(guò)多的問題。當(dāng)然線程個(gè)數(shù)參數(shù)，可以根據(jù)實(shí)際情況調(diào)整。

審核編輯：劉清