問題描述

最近有個系統在做壓力測試，

環境配置：

4核CPU 8g記憶體 jdk1.6.0_25，jvm配置-server -Xms2048m -Xmx2048m 

出現問題如下

執行併發300人，壓測持續1個小時記憶體使用率從20%上升到100%,tps從1100多降低到600多。

排查過程

top命令檢視記憶體佔用如下

然後檢視java堆記憶體分佈情況

 

檢視堆記憶體佔用正常，jvm垃圾回收也沒有異常。

然後想到了是堆外記憶體洩漏，由於系統中用的jsf介面比較多，底層都是依賴的netty。首先考慮的是java中nio包下的DirectByteBuffer,可以直接分配堆外記憶體，不過該類分配的記憶體也有大小限制的，可以直接通過-XX:MaxDirectMemorySize=1g 進行指定，並且記憶體不夠用的時候程式碼中會顯式的呼叫System.gc()方法來觸發FullGC,如果記憶體還是不夠用就會丟擲記憶體溢位的異常。為了驗證這一想法，於是在啟動引數中通過-XX:MaxDirectMemorySize=1g指定了堆外記憶體大小為1g，然後再次進行壓測，發現記憶體還是在持續增長，然後超過了堆記憶體2g和堆外記憶體1g的總和，並且也沒有發現有記憶體溢位的異常，也沒有頻繁的進行FullGC。所以可能不是nio的DirectByteBuffer佔用的堆外記憶體。

為了分析堆外記憶體到底是誰佔用了，不得不安裝google-perftools工具進行分析，安裝步驟如下:

它的原理是在java應用程式執行時，當呼叫malloc時換用它的libtcmalloc.so，這樣就能做一些統計了
下載http://download.savannah.gnu.org/releases/libunwind/libunwind-0.99-beta.tar.gz，
./configure
make
sudo make install //需要root許可權
下載http://google-perftools.googlecode.com/files/google-perftools-1.8.1.tar.gz

,
./configure --prefix=/home/admin/tools/perftools --enable-frame-pointers
make
sudo make install //需要root許可權
修改
lc_config:
sudo vi /etc/ld.so.conf.d/usr-local_lib.conf，加入/usr/local/lib(libunwind的lib所在目錄)
執行
sudo /sbin/ldconfig，使libunwind生效
在應用程式啟動前加入：
export LD_PRELOAD=/home/admin/tools/perftools/lib/libtcmalloc.so
export HEAPPROFILE=/home/admin/heap/gzip
啟動應用程式，此時會在/home/admin/heap下看到諸如gzip_pid.xxxx.heap的heap檔案，
可使用/home/admin/tools/perftools/bin/pprof --text $JAVA_HOME/bin/java test_pid.xxxx.heap來檢視
/home/admin/tools/perftools/bin/pprof --text $JAVA_HOME/bin/java gzip_22366.0005.heap > gzip-0005.txt

然後檢視分析結果如下

Total: 4504.5 MB
4413.9 98.0% 98.0% 4413.9 98.0% zcalloc
60.0 1.3% 99.3% 60.0 1.3% os::malloc
16.4 0.4% 99.7% 16.4 0.4% ObjectSynchronizer::omAlloc
8.7 0.2% 99.9% 4422.7 98.2% Java_java_util_zip_Inflater_init
4.7 0.1% 100.0% 4.7 0.1% init
0.3 0.0% 100.0% 0.3 0.0% readCEN
0.2 0.0% 100.0% 0.2 0.0% instanceKlass::add_dependent_nmethod
0.1 0.0% 100.0% 0.1 0.0% _dl_allocate_tls
0.0 0.0% 100.0% 0.0 0.0% [email protected]_2.2.5
0.0 0.0% 100.0% 1.7 0.0% Thread::Thread
0.0 0.0% 100.0% 0.0 0.0% _dl_new_object
0.0 0.0% 100.0% 0.0 0.0% [email protected]_2.2.5
0.0 0.0% 100.0% 0.0 0.0% _dlerror_run
0.0 0.0% 100.0% 0.0 0.0% allocZip
0.0 0.0% 100.0% 0.0 0.0% __strdup
0.0 0.0% 100.0% 0.0 0.0% _nl_intern_locale_data
0.0 0.0% 100.0% 0.0 0.0% addMetaName

可以看到是Java_java_util_zip_Inflater_init這個函式一直在進行記憶體分配，檢視java原始碼原來是

public GZIPInputStream(InputStream in, int size) throws IOException {
super(in, new Inflater(true), size);
 usesDefaultInflater = true;
 readHeader(in);
}

原來java中gzip解壓縮類耗盡了系統記憶體，然後跟蹤原始碼到了系統裡邊使用的SerializationUtils類，jimdb客戶端使用該工具類對儲存在快取中的key和物件進行序列化和反序列化操作，並且在對Object進行序列化和反序列化的時候用到了java的GZIPInputStream和GZIPOutputStream解壓縮功能，當大併發進行壓測的時候，就會造成記憶體洩漏，出現記憶體持續增長的問題，當壓測停止後，記憶體也不會釋放。

暫時的解決方案

1、升級jdk版本為jdk7u71 ，壓測一段時間後，發現記憶體增長有所減慢，並且會穩定在一定的範圍內，不會把伺服器的所有記憶體耗盡。猜測可能是jdk1.6版本的bug

2、儘量不要GZIPInputStream和GZIPOutputStream解壓縮功能，因為如果物件本來就不大，壓縮不了多少空間。

如真的需要解壓縮功能，最好設定解壓縮閥值，當物件大小超過閥值之後在進行解壓縮處理，不要將所有物件都進行解壓縮處理。