<rt id="bn8ez"></rt>
<label id="bn8ez"></label>

  • <span id="bn8ez"></span>

    <label id="bn8ez"><meter id="bn8ez"></meter></label>

    隨筆 - 41  文章 - 29  trackbacks - 0
    <2015年9月>
    303112345
    6789101112
    13141516171819
    20212223242526
    27282930123
    45678910

    常用鏈接

    留言簿(5)

    隨筆分類(28)

    隨筆檔案(23)

    收藏夾(6)

    Inside JVM

    Java

    java performance

    Solr

    搜索

    •  

    最新評論

    閱讀排行榜

    評論排行榜

    This article is trying to summarize what' the JVM GC log and how can we use it to analyse memory issues.

    1. How To Generate Sun JVM GC Log

    Generally, -Xloggc:d:\gc.log -XX:+PrintGCDetails is enough. Please see following details. And for the full list, please see from http://www.tagtraum.com/gcviewer-vmflags.html#sun.verbose
    -verbose:gc
    Prints out information about garbage collections to standard out. To print the same information to a file, use -Xloggc:<file>
    Example:
    [GC 325407K->83000K(776768K), 0.2300771 secs]
    [GC 325816K->83372K(776768K), 0.2454258 secs]
    [Full GC 267628K->83769K(776768K), 1.8479984 secs]

    See -Xloggc
    Supported by: 1.3, 1.4, 1.5

    -Xloggc:<file>
    Prints information about garbage collections to the specified file.
    In conjunction with -XX:+PrintGCDetails this is the best setting for the free GCViewer.
    Supported by: 1.4, 1.5

    -XX:+PrintGCDetails
    Instructs the VM to be more verbose when printing out garbage collecion data. Specifically it does not only tell you that there was a collection, but also what impact it had on the different generations.
    This flag is very useful when tuning generation sizes.
    In conjunction with -Xloggc this is the best setting for the free GCViewer.
    Example:
    2.459: [GC 2.459: [DefNew: 3967K->0K(4032K), 0.0141600 secs] 8559K->7454K(16320K), 0.0143588 secs]
    Supported by: 1.4, 1.5

    2. How To Read GC Log


    -verbose:gc prints information at every collection
      [GC 325407K                      -> 83000K                     (776768K),                                            0.2300771 secs]   
       [ GC  the combined size of live objects before GC  ->  the combined size of live objects after GC  (the total available space, not counting the space in the permanent generation),  pause time]          
      [GC 325816K->83372K(776768K), 0.2454258 secs]
      [Full GC 267628K->83769K(776768K), 1.8479984 secs]

    -XX:+PrintGCDetails for the J2SE Platform version 1.5 
    [GC [DefNew:                  64575K
        ->   959K              (64576K),                                    0.0457646 secs]  196016K                         ->                133633K            (261184K),       0.0459067 secs]]
    [GC [
    young generation:before GC -> after GC (available young generation heap),  pause time ]   entrie heap before GC -> entire heap after GC, (available heap),     pause time                 ]]

    [GC [<collector>: <starting occupancy1> -> <ending occupancy1>, <pause time1> secs] <starting occupancy3> -> <ending occupancy3>, <pause time3> secs]

    where

    <collector> is an internal name for the collector used in the minor collection

    <starting occupancy1> is the occupancy of the young generation before the collection

    <ending occupancy1> is the occupancy of the young generation after the collection

    <pause time1> is the pause time in seconds for the minor collection.

    <starting occupancy3> is the occupancy of the entire heap before the collection

    <ending occupancy3> is the occupancy of the entire heap after the collection

    <pause time3> is the pause time for the entire garbage collection. This would include the time for a major collection is one was done.




    Another way is to use GCViewer
    GCViewer is a free open source tool to visualize data produced by the Java VM options 
    -verbose:gc and -Xloggc<file>. It also calculates garbage collection related performance metrics
    (throughput, accumulated pauses, longest pause, etc.). This can be very useful when tuning the garbage collection of a particular application by changing generation sizes or setting the initial heap size.
    See here 
    for a useful summary of garbage collection related JVM parameters.

    3. How To Use GC Log

     Generally, you can see three signals
    (1)  the memory collected by young generation == the memory collected by entire heap? such as 64575K-959K=63616K, and 196016K - 133633K = 62383K, which means 63616K - 62383K =1233K memory moved from yougn generation to tenured section. If every GC will cause this operation, the memory is slowly leaking.
    (2) the trace of memory collected by GC? does it become smaller and smaller, which mean more and more memory cannot be collected. It is a very obvious sign of memory leak.
    (3) does the pause time is longer and longer? >1s is a obvious sign.

    From another side, the GC View provides a very good trace which is easier to be analysed.

    posted on 2009-03-19 22:27 Justin Chen 閱讀(8504) 評論(2)  編輯  收藏 所屬分類: Inside JVM

    FeedBack:
    # re: Inside JVM - GC(Garbage collection) Log and Analysis[未登錄] 2009-02-13 08:12 duduli
    GC 有三種機制。
    怎樣優化GC呢?


    ps:my english is so poor.  回復  更多評論
      
    # re: GC(Garbage collection) Log and Analysis - 2 of Series "Inside JVM"  2015-09-04 17:59 Performance Expert
    For free gc log analysis, send the log file to performancetestexpert@gmail.com  回復  更多評論
      
    主站蜘蛛池模板: 国产精品亚洲专一区二区三区| 亚洲福利视频网址| 免费一级特黄特色大片| 全免费a级毛片免费**视频| 亚洲一区二区三区在线| 国产无人区码卡二卡三卡免费| 亚洲国产成人精品无码区在线秒播| 桃子视频在线观看高清免费视频| 亚洲国产精品成人精品无码区在线| 成全视频在线观看免费| 亚洲综合一区二区国产精品| **真实毛片免费观看| 亚洲人成综合网站7777香蕉| 色www永久免费视频| 性生大片视频免费观看一级 | 国产在线精品一区免费香蕉 | 91亚洲精品第一综合不卡播放| 久章草在线精品视频免费观看| 亚洲成a人片在线观看中文动漫| 精品一区二区三区免费毛片爱| 亚洲人成网站在线观看播放青青| 成人午夜免费福利| 一级女性全黄久久生活片免费| 黑人精品videos亚洲人| 国产精品入口麻豆免费观看| 亚洲sm另类一区二区三区| 国产精品亚洲二区在线观看| 最新国产乱人伦偷精品免费网站| 亚洲综合免费视频| 国产免费黄色大片| 免费观看男人吊女人视频| 国产亚洲中文日本不卡二区| 亚洲一级片免费看| 亚洲大片免费观看| 亚洲AV无码一区二区三区鸳鸯影院| 亚洲午夜福利AV一区二区无码| 全免费毛片在线播放| 一级毛片免费播放男男| 亚洲欧洲国产综合| 亚洲精品第一国产综合精品99| 最近免费2019中文字幕大全|