jmap读取

jmap Memory Map 2010年08月11日

　　jmap能够打印给定的jvm过程或远程debug服务的共享对象的内存映射图或者具体的heap内存信息. 如果给定的jvm是运行在64位模式,那么你须要指定-J-d64参数,例如: jmap -J-d64 -heap pid

　　jmap在windows平台上,只能使用的情势如下:

　　jmap -dump: pid

　　跟

　　jmap -histo[:live] pid

　　jmap的命令如下:

　　jmap [ option ] pid

　　jmap [ option ] executable core

　　jmap [ option ] [server-id@]remote-hostname-or-IP

　　parameters

　　options

　　打印jvm中加载的每个共享对象,起始地址,映射的内存大小,共享对象文件的全门路.

　　-dump:[live,]format=b,file=

　　输出jvm的heap内容到文件,并使用hprof二进制形式. live子选项假如指定,儿童故事,那么只输出活的对象到文件.

　　-finalizerinfo

　　打印正等候回收的对象的信息

　　-histo[:live]

　　打印每个class的实例数目,内存占用,儿童故事,类全名信息. VM的内部类名字开头会加上前缀”*”. 如果live子参数加上后,只统计活的对象数量.

　　-permstat

　　打印classload和jvm heap长久层的信息. 包含每个classloader的名字,活泼性,山寨大王G-Five跻身全球前十大手机厂商 - 博文预览,地址,父classloader和加载的class数量. 另外,内部String的数量和占用内存数也会打印出来.

　　-F

　　强迫.在pid没有相应的时候使用-dump或者-histo参数. 在这个模式下,live子参数无效.

　　-h | -help

　　打印辅助信息

　　-J

　　传递参数给jmap启动的jvm.

　　pid

　　需要被打印配相信息的java进程id,创业与打工的区别 - 博文预览,可以用jps查问.

　　executable

　　Java executable from which the core dump was produced.

　　(可能是发生core dump的java可履行程序)

　　core

　　将被打印信息的core dump文件

　　remote-hostname-or-IP

　　远程debug服务的主机名或ip

　　server-id

　　独一id,如果一台主机上多个远程debug服务

　　最近在搞64位系统的进级,搞了一台放到恰是环境的pool中,在本来的32位下,我们定义的heap size是1024m,儿童故事,其中permsize是96m,实用70m左右.同样的配置在64位jvm里,Perm Generation直接暴掉,于是扩展至128m,适用稳固在108m左右,这里的起因是64位体系下,object占用了更大的内存, 10分钟让你明白中国为何物价高、内需拉不上去 - 博文预览,可以用 -XX:+UseCompressedOops参数紧缩(java6似乎还不支撑),然而咱们不应用.

　　经由前多少天的运行,系统还算稳定(经过上午,下战书两个网上流量顶峰期).昨天宣布后,我在晚上19点半左右enable这台测试机,早上到了公司,察看了一下运行情形.10点中左右发明jvm异样.

　　jstat -gcutil 22671 1000 1000

　　显示如下:

　　1234567

　　S0 S1 E O P YGC YGCT FGC FGCT GCT 0.00 0.00 100.00 100.00 84.71 17079 392.748 586 960.447 1353.195 0.00 0.00 100.00 100.00 84.71 17079 392.748 587 962.212 1354.960 0.00 0.00 100.00 100.00 84.71 17079 392.748 587 962.212 1354.960 0.00 0.00 100.00 100.00 84.71 17079 392.748 588 963.992 1356.740 0.00 0.00 100.00 100.00 84.71 17079 392.748 588 963.992 1356.740 0.00 0.00 100.00 100.00 84.58 17079 392.748 589 965.907 1358.655

　　jmap 22671

　　显示如下:

　　1234567891011121314151617181920212223242526272829303132333435363738394041424344454647

　　Attaching to process ID 22671, please wait...Debugger attached successfully.Server compiler detected.JVM version is 10.0-b23 using thread-local object allocation.Parallel GC with 8 thread(s) Heap Configuration: MinHeapFreeRatio = 40 MaxHeapFreeRatio = 70 MaxHeapSize = 1073741824 (1024.0MB) NewSize = 268435456 (256.0MB) MaxNewSize = 268435456 (256.0MB) OldSize = 5439488 (5.1875MB) NewRatio = 2 SurvivorRatio = 8 PermSize = 134217728 (128.0MB) MaxPermSize = 134217728 (128.0MB) Heap Usage:PS Young GenerationEden Space: capacity = 126615552 (120.75MB) used = 126615552 (120.75MB) free = 0 (0.0MB) 100.0% usedFrom Space: capacity = 52494336 (50.0625MB) used = 0 (0.0MB) free = 52494336 (50.0625MB) 0.0% usedTo Space: capacity = 70909952 (67.625MB) used = 0 (0.0MB) free = 70909952 (67.625MB) 0.0% usedPS Old Generation capacity = 805306368 (768.0MB) used = 804698024 (767.4198379516602MB) free = 608344 (0.5801620483398438MB) 99.92445806662242% usedPS Perm Generation capacity = 134217728 (128.0MB) used = 113520112 (108.26121520996094MB) free = 20697616 (19.738784790039062MB) 84.57907438278198% used

　　在上面显示的数据中,full gc频繁产生,占用了大批的资源

　　eden Space和Old Generation的heap多已经使用100%

　　于是dump jvm

　　jmap -dump:file=dump_run.hprof 22671