一、專案介紹
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??
作者：onedaylin
鏈接：club.perfma.com/article/189…
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/182752.html
標籤：其他