探索原因二

沒辦法匯報了~~~ 但是問題還是要去看看為什么會占用這么大的內(nèi)存空間的~

查看進程內(nèi)存使用

java 進程內(nèi)存使用率 84.9%，RES 6.8G。

查看堆內(nèi)使用情況

當期機器配置為 4Core 8G，堆最大5G，堆使用為不足3G左右。

使用arthas的dashboard/memory 命令查看當前內(nèi)存使用情況： 當前堆內(nèi)+非堆內(nèi)存加起來，遠不足當前RES的使用量。那么是什么地方在占用內(nèi)存？？

開始初步懷疑是『堆外內(nèi)存泄露』

開啟NMT查看內(nèi)存使用

筆者是預發(fā)環(huán)境，正式環(huán)境開啟需謹慎，本功能有5%-10%的性能損失！??！

-XX:NativeMemoryTracking=detail


jcmd pid VM.native_memory

概念 NMT displays “committed” memory, not "resident" (which you get through the ps command). In other words, a memory page can be committed without considering as aresident(until it directly accessed).

rssAnalyzer 內(nèi)存分析

筆者沒有使用，因為本功能與NMT作用類似，暫時沒有截圖了~ rssAnalyzer(內(nèi)部工具)，可以通過oss在預發(fā)/線上下載。

通過NMT查看內(nèi)存使用，基本確認是堆外內(nèi)存泄露。 剩下的分析過程就是確認是否堆外泄露，哪里在泄露。

堆外內(nèi)存分析

查了一堆文檔基本思路就是

pmap 查看內(nèi)存地址/大小分配情況

確認當前JVM使用的內(nèi)存管理庫是哪種

分析是什么地方在用堆外內(nèi)存。

內(nèi)存地址/大小分配情況

pmap 查看

pmap -x 2531 | sort -k 3 -n -r

劇透： 32位系統(tǒng)中的話，多為1M 64位系統(tǒng)中，多為64M。

strace 追蹤

由于系統(tǒng)對內(nèi)存的申請/釋放是很頻繁的過程，使用strace的時候，無法阻塞到自己想要查看的條目，推薦使用pmap。

strace -f -e"brk,mmap,munmap" -p 2853 原因: 對 heap 的操作，操 作系統(tǒng)提供了 brk()函數(shù)，C 運行時庫提供了 sbrk()函數(shù)；對 mmap 映射區(qū)域的操作，操作系 統(tǒng)提供了 mmap()和 munmap()函數(shù)。sbrk()，brk() 或者 mmap() 都可以用來向我們的進程添 加額外的虛擬內(nèi)存。Glibc 同樣是使用這些函數(shù)向操作系統(tǒng)申請?zhí)摂M內(nèi)存。

查看JVM使用內(nèi)存分配器類型

發(fā)現(xiàn)很大量為[anon]（匿名地址）的64M內(nèi)存空間被申請。通過附錄參考的一些文檔發(fā)現(xiàn)很多都提到64M的內(nèi)存空間問題(glibc內(nèi)存分配器導致的)，抱著試試看的態(tài)度，準備看看是否為glibc。

cd /opt/taobao/java/bin
ldd java

glibc為什么會有泄露

我們當前使用的glibc的版本為2.17。說到這里可能簡單需要介紹一下glibc的發(fā)展史。

『V1.0時代』Doug Lea Malloc 在Linux實現(xiàn)，但是在多線程中，存在多線程競爭同一個分配分配區(qū)(arena)的阻塞問題。

『V2.0時代』Wolfram Gloger 在 Doug Lea 的基礎上改進使得 Glibc 的 malloc 可以支持多線程——ptmalloc。

glibc內(nèi)存釋放機制(可能出現(xiàn)泄露時機)

調用free()時空閑內(nèi)存塊可能放入 pool 中，不一定歸還給操作系統(tǒng)。

.收縮堆的條件是當前 free 的塊大小加上前后能合并 chunk 的大小大于 64KB、，并且 堆頂?shù)拇笮∵_到閾值，才有可能收縮堆，把堆最頂端的空閑內(nèi)存返回給操作系統(tǒng)。

『V2.0』為了支持多線程，多個線程可以從同一個分配區(qū)（arena）中分配內(nèi)存，ptmalloc 假設線程 A 釋放掉一塊內(nèi)存后，線程 B 會申請類似大小的內(nèi)存，但是 A 釋放的內(nèi) 存跟 B 需要的內(nèi)存不一定完全相等，可能有一個小的誤差，就需要不停地對內(nèi)存塊 作切割和合并。

為什么是64M

回到前面說的問題，為什么會創(chuàng)建這么多的64M的內(nèi)存區(qū)域。這個跟glibc的內(nèi)存分配器有關下的，間作介紹。 V2.0版本的glibc內(nèi)存分配器，將分配區(qū)域分配主分配區(qū)(main arena)和非主分配區(qū)(non main arena)（在v1.0時代，只有一個主分配區(qū)，每次進行分配的時候，需要對主分配區(qū)進行加鎖，2.0支持了多線程，將分配區(qū)通過環(huán)形鏈表的方式進行管理），每一個分配區(qū)利用互斥鎖使線程對于該分配區(qū)的訪問互斥。

主分配區(qū)：可以通過sbrk/mmap進行分配。

非主分配區(qū)，只可以通過mmap進行分配。

其中,mmap每次申請內(nèi)存的大小為HEAP_MAX_SIZE（32 位系統(tǒng)上默認為 1MB，64 位系統(tǒng)默 認為 64MB）。

哪里在泄露

既然知道了存在堆外內(nèi)存泄露，就要查一下到低是什么地方的內(nèi)存泄露。參考歷史資料，可以使用jemalloc工具進行排查。

配置dump內(nèi)存工具（jemalloc）

由于系統(tǒng)裝載的是glibc，所以可以自己在不升級jdk的情況下編譯一個jemalloc。

github下載比較慢，上傳到oss，再做下載。

sudo yum install -y git gcc make graphviz 
    wget -P /home/admin/general-aftersales https://xxxx.oss-cn-zhangjiakou.aliyuncs.com/jemalloc-5.3.0.tar.bz2 &&  
    mkdir   /home/admin/general-aftersales/jemalloc && 
    cd  /home/admin/general-aftersales/ && 
    tar -jxcf  jemalloc-5.3.0.tar.bz2 && 
    cd  /home/admin/xxxxx/jemalloc-5.3.0/ && 
    ./configure  --enable-prof && 
    make && 
    sudo make install


export LD_PRELOAD=/usr/local/lib/libjemalloc.so.2  MALLOC_CONF="prof:true,lg_prof_interval:30,lg_prof_sample:17,prof_prefix:/home/admin/general-aftersales/prof_prefix

核心配置

make之后，需要啟用prof，否則會出現(xiàn)『: Invalid conf pair: prof:true』類似的關鍵字

配置環(huán)境變量

LD_PRELOAD 掛載本次編譯的庫

MALLOC_CONF 配置dump內(nèi)存的時機。

"lg_prof_sample:N"，平均每分配出 2^N 個字節(jié) 采一次樣。當 N = 0 時，意味著每次分配都采樣。

"lg_prof_interval:N"，分配活動中，每流轉 1 ? 2^N 個字節(jié)，將采樣統(tǒng)計數(shù)據(jù)轉儲到文件。

重啟應用

./appctl restart

監(jiān)控內(nèi)存dump文件

如果上述配置成功，會在自己配置的prof_prefix 目錄中生成相應的dump文件。 然后將文件轉換為svg格式

jeprof --svg /opt/taobao/java/bin/java prof_prefix.36090.9.i9.heap > 36090.svg

與參閱文檔中結果一致，有通過Java java.util.zip.Inflater調用JNI申請內(nèi)存，進而導致了內(nèi)存泄露。

既然找到了哪里存在內(nèi)存泄露，找到使用的地方就很簡單了。

發(fā)現(xiàn)元兇

通過arthas 的stack命令查看某個方法的調用棧。

statck java.util.zip.Inflater 

java.util.zip.InflaterInputStream

如上源碼可以看出，如果使用InflaterInputStream(InputStream?in)?來構造對象usesDefaultInflater=true， 否則全部為false; 在流關閉的時候。

end()是native方法。

只有在『usesDefaultInflater=true』的時候，才會調用free()將內(nèi)存歸嘗試歸還OS，依據(jù)上面的內(nèi)存釋放機制，可能不會歸還，進而導致內(nèi)存泄露。

comp.taobao.pandora.loader.jar.ZipInflaterInputStream

二方包掃描

ZipInflaterInputStream 的流關閉使用的是父類java.util.zip.InflaterInputStream，構造器使用public?InflaterInputStream(InputStream?in,?Inflater?inf,?int?size) 這樣如上『usesDefaultInflater=false』，在關閉流的時候，不會調用end()方法，導致內(nèi)存泄露。 com.taobao.pandora.loader.jar.ZipInflaterInputStream 源自pandora ，咨詢了相關負責人之后，發(fā)現(xiàn)2年前就已經(jīng)修復此內(nèi)存泄露問題了。

最低版本要求 sar包里的 pandora 版本，要大于等于 2.1.17

問題解決

升級ajdk版本

需要咨詢一下jdk團隊的同學，需要使用jemalloc作為內(nèi)存分配器的版本。

升級pandora版本

如上所說，版本高于2.1.17即可。

我們是團隊是統(tǒng)一做的基礎鏡像，找相關的同學做了dockerfile from的升級。

發(fā)布部署&觀察

這此真的舒服了~ ?

總結

探究了glibc的工作原理之后，發(fā)現(xiàn)相比jemalloc的內(nèi)存使用上確實存在高碎片率的問題，但是本次問題的根本還是在應用層面沒有正確的關閉流加劇的堆外內(nèi)存的泄露。

總結的過程，也是學習的過程，上述分析過程歡迎評論探討。

審核編輯：湯梓紅