執行緒說：不是我想爆炸，只怪你Nd4j沒用好
一、專案介紹
web_rec_comm_ctr
背景：
去年接手了一個排序服務，用於播單、聲音、主播排序。接手以來處理過記憶體溢位問題，後面也沒再出現過其他狀況。但是最近該專案用於離線任務計算後，出現了問題。並且問題發生時間是在計算量擴量之後。
專案背景：
- 該專案與演算法的配合方式：專案提供介面規範，涉及：排序演算法載入、自動更新、模型呼叫、輸入引數解析、告知模型所需特徵資料（包括特徵表、表字段等）。
- 專案需要做的事：載入演算法–>解析請求資料–>獲取特徵資料–>呼叫模型排序–>解析排序結果–>結果拼裝返回。
二、問題背景
1、發現專案的k8s容器會出現重啟現象。
發生問題時，容器配置：CPU：4個：排序計算需要； 記憶體：堆內6G：w2v模型本地載入； 堆外3G：各種演算法包計算使用。
三、問題結論：
Nd4j計算框架在做計算時（使用了OpenMP庫：OpenMP是一個開源的並行程式設計API，支援C/C++/Fortran語言。ND4j使用以C++編寫的後端，因此我們用OpenMP來改善CPU的平行計算效能。），庫裡面直接呼叫pthread_create進行執行緒建立，多執行緒平行計算。由於對該領域的包不是很瞭解，就不深挖該計算框架的優化。直接摒棄該庫採用其他方式做計算。
四、問題排查流程
檢視監控系統，觀察重啟發生時，容器例項的資源情況
注：先別急著納悶這個專案的監控資料圖看著那麼多毛刺。這個排序服務是為離線定時任務服務的。
監控資料觀察：
- 首先，執行緒數呈現出異常情況，最高接近8k。
- 其次，發現最開始出現問題的時候，任務的資料量是比較少量，而不是大量計算才發生問題。
- 第三，大部分情況下，重啟的時間剛好跟執行緒達到峰值對上。連續重啟一般是：上一次重啟的時候，服務擁入大量請求，執行緒陡增，然後又重啟了…
- 第四，也不是每一次任務觸發都會發生重啟，且根據執行緒圖可以知道，執行緒是有進行回收的動作，不大可能是永久資源洩漏。好熟悉的感覺，難道又是資源使用後沒釋放，直到垃圾回收時被動釋放資源…
根據第一點，在下次任務來臨時，dump下執行緒棧：jstack pid，使用執行緒分析網站：fastThread
此時我的表情是這樣的：
- 說好的8k個執行緒呢…難道是…我開啟的方式不對…好吧，愣了一下。jstack命令dump下來的執行緒一般是由jvm生成的管理的執行緒，而native方法產生的執行緒是不由jvm進行管理的，這也就是為啥jstack命令dump下來的執行緒棧就只有這麼一點。
- 注：別妄想用jstack -m引數dump執行緒，說實話，dump下來的東西看了之後心態更蹦，好吧其實是我看不懂。
- 通過跟運維大佬請教，監控中使用了ps命令的-L引數，使用ps -efL | grep pid | wc -l果然跟監控系統的統計是對的上的。
- 此時懷疑是本地執行緒使用氾濫導致的。
定位那些native執行緒是由什麼建立的：（以下方法來自李老師的指導，向李老師學習。）
- 這個時候只能祭出cat /proc/$pid/maps了，至於maps檔案是幹嘛的…嗯，可以參考一下：/proc/{pid}/maps解讀，虛擬記憶體 、 linux proc maps檔案分析
- 然後用pstack看看那些多餘的執行緒堆疊的是什麼，用地址對比一下就找到openmp這個庫了。
- 根據上圖可以鎖定mkl和nd4j，在專案中瞅瞅是哪裡引入：mvn dependency:tree
-
該庫的引入來自於演算法同事提供的模型計算包。翻看程式碼中，在做計算時確實用到了該庫，以下隨機抽了使用片段。
public float[] userWord2Vec(List<HashMap<String, Object>> list, Word2VEC word2vecModel, int audioVectorDim, int topK, boolean norm){ /*
* @描述: 獲取使用者的分散式表示[將播放序列的節目向量的和或者均值作為使用者的向量表示] * @引數: [list, topK, norm] * @返回值: float[] * @建立時間: 7/23/19 */ float[] userVec_ = new float[audioVectorDim]; INDArray userVec = Nd4j.create(userVec_, new int[]{1, audioVectorDim}); 複製程式碼 -
翻看演算法同事的程式碼發現，INDArray物件使用後，並未做資源釋放，嘗試修改程式碼，在計算後，對使用的資源進行釋放。但遺憾的是，儘管加入釋放程式碼，發版後依然出現相同的狀況。
-
此時只能硬著頭皮翻翻原始碼了，畢竟問題現象是執行緒氾濫，看看有沒有地方可以設定，限制該庫的執行緒使用數，犧牲併發度。以下為org.nd4j:nd4j-api:jar:1.0.0-beta4:compile依賴下ExecutorServiceProvider類原始碼
public class ExecutorServiceProvider {
public static final String EXEC_THREADS = "org.nd4j.parallel.threads"; public final static String ENABLED = "org.nd4j.parallel.enabled"; private static final int nThreads; private static ExecutorService executorService; private static ForkJoinPool forkJoinPool; static { int defaultThreads = Runtime.getRuntime().availableProcessors(); boolean enabled = Boolean.parseBoolean(System.getProperty(ENABLED, "true")); if (!enabled) nThreads = 1; else nThreads = Integer.parseInt(System.getProperty(EXEC_THREADS, String.valueOf(defaultThreads))); } 複製程式碼 -
通過上圖，嘗試在啟動引數里加入-Dorg.nd4j.parallel.enabled=false，直接將併發計算一刀切。so sad，結果依然是執行緒氾濫。此處設定應該是限制單次計算由並行改為單執行緒計算，並沒有解決執行緒資源未回收的問題。
-
無奈只能求助google：工作區指南 、Deeplearning4j的本機CPU優化 嘗試修改執行緒、垃圾回收等配置，但依然毫無改善問題。（ND4J確實不瞭解，工作區概念什麼的也看懵了…）
五、解決方案
最終只能求助於演算法大佬，看能否換其他庫做計算或者自己實現計算。首先確認改動成本有多大，確保以最小的代價去解決：
- 該專案中大部分排序演算法已遷移到“模型服務平臺”中，剩餘的演算法也只是支援少量的計算工作，所以此處僅需修改在還在改專案中使用的演算法。（嗯…其實就剩兩個了。）
- 使用到的演算法中，對於Nd4j的使用是在於矩陣計算，而非複雜的模型訓練或者模型計算。所以替換的計算邏輯完全可以由其他工具包快速替換或者快速手寫實現。
- 演算法大佬修改實現後，重新引入發版觀察。謝天謝地，總算迴歸正常。
- 其實在解決發版後，又偷偷發了一個節點，版本是解決問題前的。將記憶體提升到15G，堆內依然是6G，堆外預留9G。留著該節點且預留大堆外記憶體是為了驗證本次修改是否解決問題。果然該節點發版後，雖然未出現重啟現象。但是其記憶體一度超過9G，如果未擴容，應該又是一次重啟。且執行緒數又出現陡增情況。但是執行緒又出現回收情況，此處猜想是GC帶來的影響，堆內的物件被回收之後，其指向外部的資源也被回收利用了。後續有時間將瞭解一番。現在持續觀察是否再出現問題。
六、總結
涉及native方法呼叫的第三發庫使用最好先了解其工作原理再進行使用，儘量能做到資源使用可控，及時釋放資源。雖然本次問題觸及的知識領域比較陌生，還是儘可能去了解自己專案裡面引入的東西會該來什麼影響。
看完三件事❤️
如果你覺得這篇內容對你還蠻有幫助，我想邀請你幫我三個小忙：
-
點贊，轉發，有你們的 『點贊和評論』，才是我創造的動力。
-
關注公眾號 『 java爛豬皮 』，不定期分享原創知識。
-
同時可以期待後續文章ing