JVM performance tuning tool documentation
- JPS: tool for vm process status
options | role |
---|---|
-q | Output only LVMID, omitting the name of the main class |
-m | Prints the arguments passed to the mian() function of the main class when the virtual machine process starts |
-l | Prints the full name of the main class, and the Jar path if the process executes a Jar package |
-v | Output THE JVM parameters for starting the virtual machine process |
- jstat
options | role |
---|---|
class | Used to view the statistics of class loading, such as the number of loaded classes, and the space occupied. |
compiler | View real-time compiler compilation statistics in HotSpot |
gc | View garbage collection statistics for the heap in the JVM to display information about gc, the number of gc, and when. The last five items are respectively the number of young gc, the time of young GC, the number of full GC, the time of full GC, and the total time of GC. |
gccapacity | Viewing the storage capacity of the new generation,old generation, and persistent generation, you can view the usage and occupation of three generations (young,old,perm) objects in VM memory |
gccause | View garbage collection statistics (this is the same as the -gcutil option), and if a garbage collection occurred, it also shows the reason for the last and current garbage collection |
gcmetacapacity | Displays statistics about metaspace size. |
gcnew | View new generation garbage collection, new object information |
gcnewcapacity | Used to view the storage capacity of the new generation, information about new objects and their usage |
gcold | Used to view information about old objects when GC occurs in old generation and persistent generation |
gcoldcapacity | View the capacity of old generation, information about old objects and their usage |
gcpermcapacity | View persistent generation capacity, perm object information and usage |
gcutil | View new generation, old generation, and legacy garbage collection |
printcompilation | Information about current VM execution |
- Jinfo: allows you to view and adjust VM parameters in real time.
Can use – flag [+ | -] name or flag – name = value at runtime to modify part of runtime writable virtual machine jinfo pid parameter values
Query CMSInitiatingOccupancyFraction parameter values:
jinfo -flag CMSInitiatingOccupancyFraction 1444
- jmap
options | role |
---|---|
heap | Displays Java heap details |
histo | Displays statistics about objects in the heap |
clstats | Prints class loader information |
finalizerinfo | Objects in the F-Queue whose Finalizer method is executed by the Finalizer thread are displayed |
dump | Generates a heap dump snapshot |
F | When -dump does not respond, the -dump or -histo parameters are used. In this mode, the live subparameter is invalid. |
help | Printing Help Information |
J | Specifies the parameters passed to the JVM running JMap |
jmap -dump:format=b,live,file=test.bin 8428
- jhat
Jhat test.bin Visit http://localhost:7000/
- jstack
options | role |
---|---|
-F | Forces the output thread stack when a normally entered request is not responded to |
-m | C/C++ stacks can be displayed if local methods are called |
-l | Displays additional information about locks in addition to the stack |
Common interface tool JAVA VisualVM
GC overhead limit exceeded hit JVM optimization
In my daily work, THERE are few problems related to JVM optimization. The problems I understand are: the selection of garbage collector under applicable scenarios for the new generation and the old generation, Eden: From Survivor: To Survivor of the golden ratio tuning, the best age from the new generation To the old age problem, has not encountered this aspect of the scene, is not here stubborn. Second, the stack memory setup problem. The following is a simple record of a simple optimization experience. The length of the article is reserved, and there will be continuous updates in the later work. Although not very deep optimization experience, but the JVM knowledge reserve is still some research, for JUC learning and dealing with emergency scenarios to solve the idea is very helpful.
Project development framework SpringCloud architecture, user information batch collection, for a large amount of user data batch storage, interface can not make a timely response, so we use RabbitMq when users upload the file information as a producer to the message queue, consumers use POI user mode for asynchronous consumption processing. For the back end, there is a number of verification files. The user information of 2W users is collected at a time, but the user does not upload according to the template. An Excel file with a very long column and a size of 100M has less than 1W data pieces. There is a GC overhead limit exceeded log that caught my attention.
Solution: Increase heap initialization size and maximum size parameters:
-Xmx Maximum Java Heap size. The default value is 1/4 of the physical memory. The optimal value depends on the size of the physical memory and other memory overhead on the computer.
-xms Java Heap initial value, Server JVM preferably set -xms and -xmx to the same value,
Delete error messages and add file size verification.
Backup method: POI+SAX mode can be used to parse millions of pieces of data without overflow of memory. At that time, this method was not used to provide, requiring large code change momentum.