技術文章 » 糟了，線上服務出現OOM了

糟了，線上服務出現OOM了

2022-10-10 21:00:29

前言

前一段時間，公司同事的一個線上服務OOM的問題，我覺得挺有意思的，在這裡跟大家一起分享一下。

我當時其實也參與了一部分問題的定位。

1 案發現場

他們有個mq消費者服務，在某一天下午，出現OOM了，導致服務直接掛掉。

當時我們收到了很多記憶體的報警郵件。

發現問題之後，運維第一時間，幫他們dump了當時的記憶體快照，以便於開發人員好定位問題。

之後，運維重啟了該服務，系統暫時恢復了正常。

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

但重啟服務治標不治本，只能臨時解決一下問題，如果不找到真正的原因，難免下次在某個不經意的時間點，又會出現OOM問題。

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

2 初步定位問題

當時運維dump下來的記憶體快照檔案有3G多，太大了，由於公司內網限制，沒辦法及時給到開發這邊。

沒辦法，只能先從紀錄檔檔案下手了。

在查紀錄檔之前，我們先檢視了prometheus上的服務監控。查到了當時那個mq消費者服務的記憶體使用情況，該服務的記憶體使用率一直都比較平穩，從2022-09-26 14:16:29開始，出現了一個明顯的記憶體飆升情況。

根據以往經驗總結出來的，在追查紀錄檔時，時間點是一個非常重要的過濾條件。

所以，我們當時重點排查了2022-09-26 14:16:29前後5秒鐘的紀錄檔。

由於這個服務，並行量不大，在那段時間的紀錄檔量並不多。

所以，我們很快就鎖定了excel檔案匯入匯出功能。

該功能的流程圖如下：

  1. 使用者通過瀏覽器上傳excel，呼叫檔案上傳介面。
  2. 該介面會上傳excel到檔案伺服器。然後將檔案url，通過mq訊息，傳送到mq伺服器。
  3. mq消費者消費mq訊息，從檔案伺服器中獲取excel資料，做業務處理，然後把結果寫入新的excel中。
  4. mq消費者將新excel檔案上傳到檔案伺服器，然後發websocket訊息通知使用者。
  5. 使用者收到通知結果，然後可以下載新的excel。

經過紀錄檔分析，時間點剛好吻合，從excel檔案匯入之後，mq消費者服務的記憶體使用率一下子飆升。

3. 打不開dump檔案

從上面分析我們得出初步的結論，線上mq消費者服務的OOM問題，是由於excel匯入匯出導致的。

於是，我們檢視了相關excel檔案匯入匯出程式碼，並沒有發現明顯的異常。

為了找到根本原因，我們不得不把記憶體快照解析出來。

此時，運維把記憶體快照已經想辦法發給了相關的開發人員（我的同事）。

那位同事用電腦上安裝的記憶體分析工具：MAT（Memory Analyzer Tool），準備開啟那個記憶體快照檔案。

但由於該檔案太大，佔了3G多的記憶體，直接開啟失敗了。

MemoryAnalyzer.ini檔案預設支援開啟的記憶體檔案是1G，後來它將引數-xmx修改為4096m。

修改之後，檔案可以開啟了，但開啟的內容卻有問題。

猛然發現，原來是JDK版本不匹配導致的。

他用的MAT工具是基於SunJDK，而我們生成環境用的OpenJDK，二者有些差異。

SunJDK採用JRL協定釋出，而OpenJDK則採用GPL V2協定釋出。兩個協定雖然都是開放原始碼的，但是在使用上的不同，GPL V2允許在商業上使用，而JRL只允許個人研究使用。

所以需要下載一個基於OpenJDK版本的MAT記憶體分析工具。

4. 進一步分析

剛好，另一個同事的電腦上下載過OpenJDK版本的MAT記憶體分析工具。

把檔案發給他幫忙分析了一下。

最後發現org.apache.poi.xssf.usermodel.XSSFSheet類的物件佔用的記憶體是最多的。

目前excel的匯入匯出功能，大部分是基於apache的POI技術，而POI給我們提供了WorkBook介面。

常用的WorkBook介面實現有三種：

  • HSSFWorkbook：它是早期使用最多的工具，支援Excel2003以前的版本，Excel的擴充套件名是.xls。只能匯出65535條資料，如果超過最大記錄條數會報錯，但不會出現記憶體溢位。
  • XSSFWorkbook：它可以操作Excel2003-Excel2007之間的版本，Excel的擴充套件名是.xlsx。最多可以匯出104w條資料，會建立大量的物件存放到記憶體中，可能會導致記憶體溢位。
  • SXSSFWorkbook：它可以操作Excel2007之後的所有版本，Excel的擴充套件名是.xlsx。 SXSSFWorkbook是streaming版本的XSSFWorkbook，它只會儲存最新的rows在記憶體裡供檢視，以前的rows都會被寫入到硬碟裡。用磁碟空間換記憶體空間，不會導致記憶體溢位。

看到了這個類，可以驗證之前我們通過紀錄檔分析問題，得出excel匯入匯出功能引起OOM的結論，是正確的。

那個引起OOM問題的功能，剛好使用了XSSFWorkbook處理excel，一次性建立了大量的物件。

關鍵程式碼如下：

XSSFWorkbook wb = new XSSFWorkbook(new FileInputStream(file));
XSSFSheet sheet = wb.getSheetAt(0);

我們通過MAT記憶體分析工具，已經確定OOM問題的原因了。接下來，最關鍵的一點是：如何解決這個問題呢？

5. 如何解決問題？

根據我們上面的分析，既然XSSFWorkbook在匯入匯出大excel檔案時，會導致記憶體溢位。那麼，我們改成SXSSFWorkbook不就行了？

關鍵程式碼改動如下：

XSSFWorkbook wb = new XSSFWorkbook(new FileInputStream(file));
SXSSFWorkbook swb = new SXSSFWorkbook(wb,100);
SXSSFSheet sheet = (SXSSFSheet) swb.createSheet("sheet1");

使用SXSSFWorkbook將XSSFWorkbook封裝了一層，其中100表示excel一次讀入記憶體的最大記錄條數，excel中其餘的資料將會生成臨時檔案儲存到磁碟上。這個引數，可以根據實際需要調整。

還有一點非常重要：

sheet.flushRows();

需要在程式的結尾處加上上面的這段程式碼，不然生成的臨時檔案是空的。

這樣調整之後，問題被暫時解決了。

此外，順便說一句，在使用WorkBook介面的相關實現類時，用完之後，要記得呼叫close方法及時關閉喔，不然也可能會出現OOM問題。

6. 後續思考

其實，當時我建議過使用阿里開源的EasyExcel解決OOM的問題。

但同事說，excel中有很多樣式，在匯出的新excel中要保留之前的樣式，同時增加一列，返回匯入的結果。

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

但是使用mq非同步匯入excel檔案這套方案，如果並行量大的話，任然可能會出現OOM問題，有安全隱患。

因此，有必要調整一下mq消費者。

後來，mq消費者的執行緒池，設定成4個執行緒消費，避免mq消費者同時處理過多的訊息，讀取大量的excel，導致記憶體佔用過多的問題。當然執行緒個數引數，可以根據實際情況調整。

此外，使用阿里的arthas也可以定位線上OOM問題，後面會有專門的文章介紹，感興趣的小夥伴可以關注一下。

最後說一句(求關注，別白嫖我)

如果這篇文章對您有所幫助，或者有所啟發的話，幫忙掃描下發二維條碼關注一下，您的支援是我堅持寫作最大的動力。

求一鍵三連：點贊、轉發、在看。

關注公眾號：【蘇三說技術】，在公眾號中回覆：面試、程式碼神器、開發手冊、時間管理有超讚的粉絲福利，另外回覆：加群，可以跟很多BAT大廠的前輩交流和學習。