jvmメモリ診断コレクション

6958 ワード
java linux ビッグデータ python プログラミング言語
jvmメモリ診断はずっと強い需要で、みんなはすぐにmatなどのツールを考えることができて、heap、metaspaceを診断して、直接メモリの上で奇効があります.しかしjvmの問題の一部を解決できることを紹介します.次は、全面的な診断方法です.
nmtを用いて漏れ領域を探し出す
JAvaにはNativeMemoryTrackingがあり、jvmがもたらすメモリ割り当ての問題を表示するのに役立ちます.これはjvmがもたらすメモリしか見られません.jniの呼び出し申請のメモリであれば、このツールは役に立ちません.では、皆さんは疑問に思っているかもしれませんが、このツールも想像していたほど役に立ちません.javaの様々なパーティション、スタック、非スタック、直接メモリの値jmxもあります.jvmがもたらしたものかどうかを調べてもいいようです.NativeMemoryTrackingの役割は何ですか?
既存のツールと比較
メモリデータを表示するツールは実はたくさんありますが、NativeMemoryTrackingで彼らと比較してみましょう.jstat|NativeMemoryTracking|jmx|||-|-|-|-||||コマンドラインウォッチをサポートしているかどうか|サポートしているかどうか|サポートしていない|直接メモリをサポートしているかどうか|サポートしていない|サポートしていない|サポートしているかどうか|unsafeの割り当てをサポートしているかどうか|サポートしていない|サポートしていない|サポートしていない|対比の最後の項目について、直接メモリはunsafeの割り当てを利用しているのではないかと疑問を提起するでは、ここではどうしてjmxがサポートしていないと書いたのでしょうか.ダイレクトメモリの使用は、DirectByteBuffer自身が維持しているメモリの数です.つまりこの直接メモリのデータはjava codeが自分でメンテナンスしたもので、これらをスキップすれば、直接彼の下位実装方式unsafeを手に入れることができます.allocateMemory(size);このデータは直接メモリで統計されませんが、nmtはできます.対照的に、nmtの機能と優位性を理解することができます.彼は非グラフィックスインタフェースを提供し、topと協力して、メモリが誰を占めているのかを迅速に区別することができます.nmtのデータが増加していない場合、topのresが上昇したのは、jniの呼び出しによる可能性があることを示しています.jvmのメモリが増加している場合、detailで見ることができます.
nmtを上手に使う
直接メモリのdemoテストを持ってきます.
public class Malloc {
    public static void main(String[] args) {
        new Thread(()->{
            int i=0;

            List s= new LinkedList();
            while (i<10){
                ByteBuffer buffer = ByteBuffer.allocateDirect(1024*1024*100);

                s.add(buffer);
                System.out.println("malloc");
                i++;
                try {
                    Thread.sleep(3000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }



        }).start();
        new Thread(()->{
            int i=0;
            while (i<10){
                byte[] bytes =new byte[1024*1024*10];

            }
        }).start();
    }
}

nmt機能を起動します.
-XX:NativeMemoryTracking=detail

baseline機能をオンにします.
jcmd pid VM.native_memory baseline

baselineを開くと、データの増加がより直感的に見え、印刷されたデータには+番号があります.まずsummary情報を見て、誰が成長しているかを見てみましょう.
jcmd pid VM.native_memory summary.diff

                            (malloc=123KB #536 +1)
                            (mmap: reserved=249600KB, committed=2536KB)

-                        GC (reserved=165933KB, committed=155689KB)
                            (malloc=12689KB #138)
                            (mmap: reserved=153244KB, committed=143000KB)

-                  Compiler (reserved=133KB, committed=133KB)
                            (malloc=2KB #32)
                            (arena=131KB #7)

-                  Internal (reserved=1035599KB +307200KB, committed=1035599KB +307200KB)
                            (malloc=1035567KB +307200KB #2102 +3)
                            (mmap: reserved=32KB, committed=32KB)

現在のテストではjava 8が使用されており、unsafeで申請したメモリはInternalにあります.それからdetailを使います.diffは誰が招いたのかを調べます.

summary ， Internal。 diff

[0x000000010cf8638b] Unsafe_AllocateMemory+0x78
[0x0000000110d99667]
                             (malloc=1024000KB type=Internal +307200KB #10 +3)

type Internal , unsafe 。

heap

unsafe demo， unsafe 。

heap，metaspace， mat ， heapdump 。 。

native

nmt ， res ， jni native 。 ， jemalloc。

jemalloc native ， 。 ubuntu 。 ， wiki 。wiki ， 。

./configure --enable-prof
make && make install

， 

/usr/bin/install -c -d /usr/local/bin
/usr/bin/install -c -m 755 bin/jemalloc-config /usr/local/bin
/usr/bin/install -c -m 755 bin/jemalloc.sh /usr/local/bin
/usr/bin/install -c -m 755 bin/jeprof /usr/local/bin
/usr/bin/install -c -d /usr/local/include/jemalloc
/usr/bin/install -c -m 644 include/jemalloc/jemalloc.h /usr/local/include/jemalloc
/usr/bin/install -c -d /usr/local/lib
/usr/bin/install -c -m 755 lib/libjemalloc.so.2 /usr/local/lib
ln -sf libjemalloc.so.2 /usr/local/lib/libjemalloc.so
/usr/bin/install -c -d /usr/local/lib
/usr/bin/install -c -m 755 lib/libjemalloc.a /usr/local/lib
/usr/bin/install -c -m 755 lib/libjemalloc_pic.a /usr/local/lib
/usr/bin/install -c -d /usr/local/lib/pkgconfig
/usr/bin/install -c -m 644 jemalloc.pc /usr/local/lib/pkgconfig
Missing xsltproc.  doc/jemalloc.html not (re)built.
Missing xsltproc.  doc/jemalloc.3 not (re)built.
/usr/bin/install -c -d /usr/local/share/doc/jemalloc
/usr/bin/install -c -m 644 doc/jemalloc.html /usr/local/share/doc/jemalloc
/usr/bin/install -c -d /usr/local/share/man/man3
/usr/bin/install -c -m 644 doc/jemalloc.3 /usr/local/share/man/man3

， 。

export MALLOC_CONF="prof_leak:true,lg_prof_sample:0,prof_final:true"
export LD_PRELOAD="/usr/local/lib/libjemalloc.so"

lg_prof_sample 2 n ， 。 ， ， 。

export MALLOC_CONF="prof:true,lg_prof_interval:4"

。

java Malloc


: Leak approximation summary: ~83261344 bytes, ~3275 objects, >= 1120 contexts
: Run jeprof on "jeprof.17013.0.f.heap" for leak detail


jeprof  /usr/bin/java jeprof.17013.0.f.heap

top 

(jeprof) top
Total: 179.4 MB
   131.0  73.0%  73.0%    131.0  73.0% je_prof_backtrace
    48.0  26.8%  99.8%     79.0  44.0% SUNWprivate_1.1
     0.4   0.2% 100.0%      0.4   0.2% Java_java_util_zip_ZipFile_getZipMessage
     0.0   0.0% 100.0%      0.0   0.0% _dl_new_object
     0.0   0.0% 100.0%      0.0   0.0% allocate_dtv
     0.0   0.0% 100.0%      0.0   0.0% _dl_check_map_versions
     0.0   0.0% 100.0%      0.4   0.2% ZIP_Unlock
     0.0   0.0% 100.0%      0.0   0.0% Java_java_util_zip_Inflater_init
     0.0   0.0% 100.0%     48.0  26.8% _dlerror_run
     0.0   0.0% 100.0%      0.0   0.0% 0x0000000000400620


sudo apt-get install  ghostscript graphviz


jeprof --show_bytes --pdf /usr/bin/java jeprof.17013.0.f.heap  > my.pdf
oracleストアド・プロシージャLoopループ1枚のテーブルを別のテーブルに挿入
yumコマンド