nodejs內存溢出 FATAL ERROR: CALL_AND_RETRY_0 Allocation failed – process out of memory

　　spa項目總體遷移轉爲ssr後，改動以後部署一切還好，就是忽然有一天訪問人數太多，node進程很容易就掛了自動重啓。

　　最後通過壓力測試，考慮到是堆內存溢出的問題，就報錯誤：FATAL ERROR: CALL_AND_RETRY_0 Allocation failed – process out of memory

一、復現結果：

　　採用Jmeter作壓力測試，1s50次，持續請求，觀察node進程佔用內存狀況

　　通過觀察發現持續請求，node進程佔用內存一直升高，最後達到1.4G左右，就不會再升，由於64位系統默認分配給node進程的上線就是1.4G，32位系統好像是0.7G。

　　達到1.4G以後，持續1/2分鐘左右，進程就掛，報錯堆內存溢出：FATAL ERROR: CALL_AND_RETRY_0 Allocation failed – process out of memory

二、解決過程

　　起初一直不知道緣由，因爲以前一直有上篇報錯：connect ECONNREFUSED 127.0.0.1:80錯誤解決，的問題，因此剛開始覺得是這個拒絕致使大量鏈接堆積致使，因此先解決了上述問題。

　　可是解決了上述問題以後，依然沒有用，仍是會報錯。考慮到是頁面的問題，因此換了一個純靜態頁面請求，看是否由於頁面代碼的問題致使內存溢出，結果請求純靜態頁面也是同樣狀況，這就不知道什麼緣由了。

　　注意：其實這時候應該考慮到往上一層，去層層篩選，應該考慮進頁面以前會有那些處理，好比nuxt裏plugins，進頁面以前就須要實例化這些東西。應該去考慮這些處理裏面會不會致使內存泄漏。

　　而我當時就是沒有考慮到這一層，因此陷入了處理問題的盲區，只能考慮到使用工具去查詢內存快照，而後再找那些地方出現內存泄漏點。

　　後來考慮到上一層，因此就往plugins裏去找，發現的確有內存泄漏的點，一樣是由於總體遷移ssr，不是從0到1搭建重構，因此代碼結構沒有過多注意。我發現全局攔截器是引入的三方axios，那麼每次攔截都會引入一次，致使大量的引用佔用資源。問題找到，改掉以後，改成引用同一個三方資源，就沒有問題了。而後把全部plugins裏重複引用的資源都改成同一份引用，這樣也能夠減小一部分佔用。

　　改好以後，build，而後用Jmeter作壓測，監控了100多萬次樣本檢測，異常率很低0.1%，而且node進程不會上升了，佔用內存穩定在200-250M之間，問題獲得解決。

　　記錄一下主要是爲了覆盤一下解決問題的思路，由於解決問題的思路比解決問題的方法更重要：應該是從底層往上層，層層篩選，底層沒問題，應該考慮緊鄰它的上一層會不會有問題，這樣就能快速定位，而我就是由於沒有繼續往上考慮一層，因此致使走了很多彎路。