生产环境由于研发人员不能随便修改,没有权限,所以只能另辟蹊径。
我这里的案例是以个人所在公司来将,研发环境、测试环境要修改某个参数,比较简单,要监控内容比较方便。生产环境只有读权限,没有写权限,运维的人也不可能帮你修改,得按流程走。
如果生产环境的应用出现无法通过日志来排查的问题,或者问题很可能与JVM有关的话,还要走完流程,才能了解JVM的状况。还有,如果要了解应用出现问题是,通过jmap生成虚拟机jump文件,也不可能,因为对于实时数据处理的应用来讲,如果设置了jvm挂掉后自动生成jump文件,不太实际,因为运维人员不可能等jvm挂了,重启应用,因为jvm在挂之前,就会出现数据接收慢、异常等问题,运维要么切备机,要么重启。
所以为了防范于未然,就要提前做好jvm监控工作。
下面就从几个方面进行了解:
一、jvm日志
要打印jvm日志,必须先了解jvm的指令
jvm的主要监控参数:
jvm监控参数 | 参数说明 | 输出示例 |
-XX:+PrintGC | 打印GC信息 | 3.830: [GC 31488K->2865K(120512K), 0.0060870 secs] |
-XX:+PrintGCDetails | 打印GC详细信息 | 1.866: [GC [PSYoungGen: 34321K->5166K(36672K)] 34321K->7105K(120512K), 0.0044310 secs] [Times: user=0.02 sys=0.01, real=0.00 secs] |
-XX:+PrintGCTimeStamps | 打印的是JVM以启动时间为基准的相对时间 | 1.650: [GC 34369K->7085K(120512K), 0.0048720 secs] |
-XX:+PrintGCDateStamps | 打印的是JVM以启动时间为基准的相对时间(以可读化的方式显示) | 2013-08-25T11:15:40.312+0800: 1.769: [GC 34321K->7084K(120512K), 0.0047500 secs] |
-XX:+PrintGCApplicationStoppedTime | 打印垃圾回收期间程序暂停的时间.可与上面混合使用 | Total time for which application threads were stopped: 0.0003350 seconds |
-Xloggc:{FilePath} | 日志信息记录到文件路径 | -Xloggc:/logs/jvm.log |
-XX:+HeapDumpOnOutOfMemoryError
| 在JVM出现内存溢出或泄露时,自动生成DUMP文件 | |
-XX:HeapDumpPath={FilePath} | DUMP文件目录 | -XX:HeapDumpPath=/logs/jvmdump/jvmDump.hprof |
推荐组合:
-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/logs/jvm.log
说明:
在/logs/jvm.log文件中记录,以yyyy-MM-ddTHH:mm:ss.sss开头方式打印JVM详细日志,
打印内容示例:
2013-08-25T11:37:18.599+0800: 1.055: [GC [PSYoungGen: 31488K->2833K(36672K)] 31488K->2833K(120512K), 0.0057740 secs] [Times: user=0.02 sys=0.00, real=0.01 secs]
红色: -XX:+PrintGCDateStamps参数打印的时间
黄色:-XX:+PrintGCDetails参数打印jvm中垃圾回收情况
蓝色:-XX:+PrintGCDetails参数打印垃圾回收耗时
绿色:-XX:+PrintGCDetails参数打印垃圾回收耗时的数据来源
jvm自动生成jump问题
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/logs/jvmdump/jvmDump.hprof
参数说明
(1)-XX:+HeapDumpOnOutOfMemoryError在JVM出现内存溢出或泄露时, 自动生成DUMP文件。
(2)-XX:HeapDumpPath=${目录}参数表示生成DUMP文件的路径,也可以指定文件名称,例 如:-XX:HeapDumpPath=${目录}/java_heapdump.hprof。如果不指定文件名,默认为:java_<pid& gt;_<date>_<time>_heapDump.hprof