問題

kettle數(shù)據(jù)采集系統(tǒng)崩潰-查看報(bào)錯(cuò)信息為：

OutOfMemoryError: Compressed class space

可以看到是內(nèi)存溢出，但是可以看到的后面的信息為 Compressed class space ，而不是java heap。

Compressed class space為壓縮類空間， 這個(gè)空間是保存在64位系統(tǒng)中類引用地址的空間，默認(rèn)大小為1G，單個(gè)類引用地址的空間是1K

意味著加載的類已經(jīng)超過1百萬，這肯定是存在問題的，需要進(jìn)一步查找問題。

內(nèi)存dump

將系統(tǒng)當(dāng)時(shí)的內(nèi)存情況dump下來進(jìn)行分析

jmap

java自帶visualVM，jmap等分析工具可以直接使用 

將當(dāng)前系統(tǒng)活躍的內(nèi)存數(shù)據(jù)寫入到kettle-test-dump-03020941.hprof 文件中，系統(tǒng)pid為18090

jmap -dump:live，format=b，file=./kettle-test-dump-03020941.hprof 18090

在實(shí)際使用時(shí)，發(fā)現(xiàn)jdk是openjdk，并未自帶jmap等工具，可以進(jìn)行升級(jí).但是怕影響系統(tǒng)運(yùn)行，另外下載了一個(gè)jdk使用

分析

使用工具進(jìn)行分析，下面介紹兩種工具進(jìn)行查看，java自帶的jvisualVM和IBM HeapAnalyzer: 

jvisualVM不需要下載，但是不會(huì)自行統(tǒng)計(jì)，需要自己寫sql來進(jìn)行深度分析 

IBM HeapAnalyzer提供表格，餅圖的方式，更加直觀的看到數(shù)據(jù)，并且會(huì)分析出最可能發(fā)生內(nèi)存泄漏的地方

jvisualVM

使用本地jdk自帶的visualVM來進(jìn)行分析查看

1.下載hprof文件到本地

2.找到j(luò)dk目錄，找到 bin/jvisualvm.exe ，雙擊打開，界面如下：

3.導(dǎo)入文件 點(diǎn)擊 文件->裝入->切換到dump文件 ->找到hprof文件打開

4.點(diǎn)開類視圖，過濾出classload ，并根據(jù)classload 找到對(duì)應(yīng)的示例和加載類的個(gè)數(shù)，數(shù)據(jù)不太直觀，但是統(tǒng)計(jì)后可以看出問題出在/org/pf4j/PluginClassLoader，根據(jù)此信息查找bug出現(xiàn)的原因。

IBM HeapAnalyzer

本來想使用MAT，但是官網(wǎng)的下載太慢等不起，正好同事安利，就使用了這個(gè)：IBM HeapAnalyzer 

1.下載hprof文件到本地

2.打開程序 找到ha457.jar包目錄

java -jar ha457.jar

打開后可以看到以下界面

3.打開下載的文件

4.查找類加載項(xiàng)

上圖中有三個(gè)表格，第一個(gè)是加載器類型表格(包括加載器類型，加載器實(shí)例數(shù)，加載器加載的類的數(shù)量)，第二個(gè)表格是單種加載器的每個(gè)實(shí)例，以及加載的數(shù)量，第三個(gè)是每個(gè)加載器實(shí)例加載的類 

可以看到 /org/pf4j/PluginClassLoader 的加載器實(shí)例有1千多個(gè)，類加載有17萬個(gè)，大概可以判定是異常數(shù)據(jù)。等待一段時(shí)間后再dump下內(nèi)存，發(fā)現(xiàn)加載的類達(dá)到30幾萬，判斷內(nèi)存溢出就是由這個(gè)加載器不斷加載類卻不釋放導(dǎo)致。 

根據(jù)第三個(gè)表格可以找到對(duì)應(yīng)的類，查找到具體原因。

總結(jié)

以上為個(gè)人經(jīng)驗(yàn)，希望能給大家一個(gè)參考，也希望大家多多支持腳本之家。

最新評(píng)論