posted 17 years ago
There was a server hang issue in the production box which was diagnosed to be a known bug in JVM 1.4.2_05 because of frequent full GCs.
The JVM was updated to 1.4.2_10. After the JVM update;I did a rudimentary GC analysis of the Prod box.
Below are the stats:
what count total mean max stddev
gen0(s) 2654 380.313 0.14330 2.402 0.1315
gen0t(s) 2654 496.903 0.18723 5.034 0.3475
gen1t(s) 7 24.664 3.52343 5.904 2.4308
GC(s) 2661 521.567 0.19600 5.904 0.4037
alloc(MB) 2654 1690802.114 637.07691 697.669 43.9602
promo(MB) 2654 14781.125 5.56938 61.672 10.9085
alloc/elapsed_time = 1690802.114 MB / 140819.293 s = 12.007 MB/s
alloc/tot_cpu_time = 1690802.114 MB / 281638.586 s = 6.003 MB/s
alloc/mut_cpu_time = 1690802.114 MB / 280595.453 s = 6.026 MB/s
promo/elapsed_time = 14781.125 MB / 140819.293 s = 0.105 MB/s
promo/gc0_time = 14781.125 MB / 496.903 s = 29.747 MB/s
gc_seq_load = 1043.133 s / 281638.586 s = 0.370%
gc_conc_load = 0.000 s / 281638.586 s = 0.000%
gc_tot_load = 1043.133 s / 281638.586 s = 0.370%
I have used the PrintGCStats script of Sun.
# Output statistics:
#
# gen0(s) - young gen collection time, excluding gc_prologue & gc_epilogue.
# gen0t(s) - young gen collection time, including gc_prologue & gc_epilogue
# cmsIM(s) - CMS initial mark pause
# cmsRM(s) - CMS remark pause
# GC(s) - all stop-the-world GC pauses
# cmsCM(s) - CMS concurrent mark phase
# cmsCP(s) - CMS concurrent preclean phase
# cmsCS(s) - CMS concurrent sweep phase
# cmsCR(s) - CMS concurrent reset phase
# alloc(MB) - object allocation in MB ***
# promo(MB) - object promotion in MB ***
The JVM Setting are as below:
-Xms3072m -Xmx3072m -XX:NewSize=768m -XX:MaxNewSize=768m -XX:SurvivorRatio=10 -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -verbose:gc
Can anybody help in the digesting the above output?
You can't wake a person who is <b><i>pretending</i></b> to be asleep.<br />Like what <b>"it"</b> does not like - <i> Gurdjieff </i>