線程說：不是我想爆炸，只怪你Nd4j沒用好

1、項目介紹

web_rec_comm_ctr

背景：

去年接手了一個排序服務，用於播單、聲音、主播排序。接手以來處理過內存溢出問題，後面也沒再出現過其餘情況。可是最近該項目用於離線任務計算後，出現了問題。而且問題發生時間是在計算量擴量以後。html

項目背景：

該項目與算法的配合方式：項目提供接口規範，涉及：排序算法加載、自動更新、模型調用、輸入參數解析、告知模型所需特徵數據（包括特徵表、表字段等）。
項目須要作的事：加載算法–>解析請求數據–>獲取特徵數據–>調用模型排序–>解析排序結果–>結果拼裝返回。

2、問題背景

一、發現項目的k8s容器會出現重啓現象。
發生問題時，容器配置：CPU：4個：排序計算須要；內存：堆內6G：w2v模型本地加載；堆外3G：各類算法包計算使用。java

3、問題結論：

Nd4j計算框架在作計算時（使用了OpenMP庫：OpenMP是一個開源的並行編程API，支持C/C++/Fortran語言。ND4j使用以C++編寫的後端，所以咱們用OpenMP來改善CPU的並行計算性能。），庫裏面直接調用pthread_create進行線程建立，多線程並行計算。因爲對該領域的包不是很瞭解，就不深挖該計算框架的優化。直接摒棄該庫採用其餘方式作計算。linux

4、問題排查流程

查看監控系統，觀察重啓發生時，容器實例的資源狀況

注：先別急着納悶這個項目的監控數據圖看着那麼多毛刺。這個排序服務是爲離線定時任務服務的。git

監控數據觀察：github

首先，線程數呈現出異常狀況，最高接近8k。
其次，發現最開始出現問題的時候，任務的數據量是比較少許，而不是大量計算才發生問題。
第三，大部分狀況下，重啓的時間恰好跟線程達到峯值對上。連續重啓通常是：上一次重啓的時候，服務擁入大量請求，線程陡增，而後又重啓了…
第四，也不是每一次任務觸發都會發生重啓，且根據線程圖能夠知道，線程是有進行回收的動做，不大多是永久資源泄漏。好熟悉的感受，難道又是資源使用後沒釋放，直到垃圾回收時被動釋放資源…

根據第一點，在下次任務來臨時，dump下線程棧：jstack pid，使用線程分析網站：fastThread

此時個人表情是這樣的：web

說好的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確實不瞭解，工做區概念什麼的也看懵了…）

5、解決方案

最終只能求助於算法大佬，看可否換其餘庫作計算或者本身實現計算。首先確認改動成本有多大，確保以最小的代價去解決：編程

該項目中大部分排序算法已遷移到「模型服務平臺」中，剩餘的算法也只是支持少許的計算工做，因此此處僅需修改在還在改項目中使用的算法。（嗯…其實就剩兩個了。）
使用到的算法中，對於Nd4j的使用是在於矩陣計算，而非複雜的模型訓練或者模型計算。因此替換的計算邏輯徹底能夠由其餘工具包快速替換或者快速手寫實現。

算法大佬修改實現後，從新引入發版觀察。謝天謝地，總算迴歸正常。

其實在解決發版後，又偷偷發了一個節點，版本是解決問題前的。將內存提高到15G，堆內依然是6G，堆外預留9G。留着該節點且預留大堆外內存是爲了驗證本次修改是否解決問題。果真該節點發版後，雖然未出現重啓現象。可是其內存一度超過9G，若是未擴容，應該又是一次重啓。且線程數又出現陡增狀況。可是線程又出現回收狀況，此處猜測是GC帶來的影響，堆內的對象被回收以後，其指向外部的資源也被回收利用了。後續有時間將瞭解一番。如今持續觀察是否再出現問題。

6、總結

涉及native方法調用的第三發庫使用最好先了解其工做原理再進行使用，儘可能能作到資源使用可控，及時釋放資源。雖然本次問題觸及的知識領域比較陌生，仍是儘量去了解本身項目裏面引入的東西會該來什麼影響。後端

看完三件事❤️

若是你以爲這篇內容對你還蠻有幫助，我想邀請你幫我三個小忙：api

點贊，轉發，有大家的『點贊和評論』，纔是我創造的動力。
關注公衆號『 java爛豬皮 』，不按期分享原創知識。
同時能夠期待後續文章ing🚀
歡迎關注做者gitee，但願共同窗習