Since R&D personnel cannot modify the production environment without permission, they can only find another way.
My case here is based on the company where the individual works. It is relatively simple to modify a certain parameter in the R&D environment and test environment, and it is more convenient to monitor the content. The production environment only has read permission, not write permission, and the operation and maintenance personnel cannot help you to modify it. You have to follow the process.
If the application in the production environment has problems that cannot be checked through logs, or if the problem is likely to be related to the JVM, you need to go through the process to understand the status of the JVM. Also, if you want to know that there is a problem with the application, it is impossible to generate a virtual machine jump file through jmap, because for the application of real-time data processing, it is not practical to automatically generate a jump file after the jvm hangs up, because It is impossible for the operation and maintenance personnel to wait for the jvm to hang up and restart the application, because before the jvm hangs, there will be problems such as slow data reception and abnormality, and the operation and maintenance will either switch to the standby machine or restart.
Therefore, in order to prevent it from happening, it is necessary to do a good job of jvm monitoring in advance.
Here are a few aspects to understand:
1. JVM log
To print the jvm log, you must first understand the instructions of the jvm
The main monitoring parameters of jvm:
| jvm monitoring parameters | Parameter Description | output example |
| -XX:+PrintGC | print GC info | 3.830: [GC 31488K->2865K(120512K), 0.0060870 secs] |
| -XX:+PrintGCDetails | print GC details | 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 | Prints the relative time of the JVM based on the startup time | 1.650: [GC 34369K->7085K(120512K), 0.0048720 secs] |
| -XX:+PrintGCDateStamps | Prints the relative time of the JVM based on the startup time (displayed in a readable way) | 2013-08-25T11:15:40.312+0800: 1.769: [GC 34321K->7084K(120512K), 0.0047500 secs] |
| -XX:+PrintGCApplicationStoppedTime | Print the time the program was paused during garbage collection. Can be mixed with the above | Total time for which application threads were stopped: 0.0003350 seconds |
| -Xloggc:{FilePath} | Log information is recorded to the file path | -Xloggc:/logs/jvm.log |
| -XX:+HeapDumpOnOutOfMemoryError
|
Automatically generate DUMP files when JVM overflows or leaks memory | |
| -XX:HeapDumpPath={FilePath} | DUMP file directory | -XX:HeapDumpPath=/logs/jvmdump/jvmDump.hprof |
Recommended combination:
-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/logs/jvm.log
illustrate:
Record in the /logs/jvm.log file, print the JVM detailed log starting with yyyy-MM-ddTHH:mm:ss.sss,
Example of what to print:
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]
Red : -XX:+PrintGCDateStamps parameter print time
Yellow : -XX:+PrintGCDetails parameter prints garbage collection in jvm
Blue : -XX:+PrintGCDetails parameter prints garbage collection time
Green : The -XX:+PrintGCDetails parameter prints the data source of the time-consuming garbage collection
jvm automatically generates jump problems
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/logs/jvmdump/jvmDump.hprof
Parameter Description
(1) -XX:+HeapDumpOnOutOfMemoryError Automatically generate a DUMP file when the JVM overflows or leaks memory.
(2) The -XX:HeapDumpPath=${directory} parameter indicates the path to generate the DUMP file, and the file name can also be specified, for example: -XX:HeapDumpPath=${directory}/java_heapdump.hprof. If no file name is specified, the default is: java_<pid& gt;_<date>_<time>_heapDump.hprof