1. JVM memory key parameters
Parameters are set in the tomcat / bin / catalina.sh in
-server: server mode, the default configuration is not -client, must be as the first parameter.
-Xms and -Xmx: minimum and maximum stack. Maybe online value must be consistent. Set as to avoid the re-allocation after each GC heap size. Stack recommended maximum set at 80% of maximum available memory (or use the free command cat / proc / meminfo view, the actual available physical memory = free + buffer + cache). But if it is set to 80%, using the server's memory may be too high to be down a little.
-Xmn: set the size of the young generation heap memory, and the rest of the old generation size. This value greater impact on system performance, Sun official recommended configuration for the entire heap 3/8
-XX: NewRatio: represents the ratio of the young generation and the old generation removed -Xmn this parameter, use the default parameters, the ratio is 2, which is 1/3 of the young generation
-XX: SurvivorRatio: setting the ratio of area and two survivor eden region, is set to 8, the ratio of the two regions with a Survivor Eden zone is 2: 8, a Survivor young generation area 1/10 of the total
-XX: PermSize and -XX: MaxPermSize (jdk1.7): Permanent substituting the initial value, the default is the 64th of physical memory, a permanent generation of maximum 1/4 of the default physical memory. Recommendations were set to 128, 512
-XX: MetaspaceSize and -XX: MaxMetaspaceSize (jdk1.8): ditto
-Xss: set the stack size for each thread. Each thread has a stack for storing function call, such as the return address, the default is 1M, generally without modification.
-XX: + AlwaysPreTouch: jvm activated when the allocation of memory, is actually a warm-up effect.
-XX: + HeapDumpOnOutOfMemoryError -XX: HeapDumpPath = path_address: jvm crash when the heap will print out information
If there are no set catalina.sh -Xms -Xmx -Xmn equivalent, can be viewed at the following pages, Reference: https://blog.51cto.com/11009785/2396840
2. GC-related parameters
-XX: + UseConcMarkSweepGC: CMS, concurrent collector (for old generation)
-XX: CMSInitiatingOccupancyFraction = 75 and -XX: + used together UseCMSInitiatingOccupancyOnly, CMS starts setting GC (control frequency, often decrease) in the memory occupancy rate of 75% of the time, use the second parameter that is set forth above value. The default value is -1, use the following command to view the value of which 2713 instead of java pid (via ps -ef | grep java View)
jinfo -flag CMSInitiatingOccupancyFraction 2713
However, keep in mind that in most cases, JVM than we ourselves can make better decisions garbage collection. Therefore, only when the life of the object we are good reasons (such as testing) and application generated a profound knowledge, you should use this flag.
-XX: + ExplicitGCInvokesConcurrent: GC parallel execution in the CMS, not pause, improve efficiency GC
-XX: + ParallelRefProcEnabled and -XX: + used together CMSParallelInitialMarkEnabled, parallel execution in CMS, reducing the pause time
-XX: + CMSScavengeBeforeRemark: Before CMS GC to perform a ygc ( ygc for the young generation, CMS GC for the old generation ), and avoid CMS GC ygc perform together to increase the pause time
-XX: + UseCMSCompactAtFullCollection: the CMS is not Heap fragmentation, coupled with this parameter can sort of live objects, reducing the memory chips
-XX: + CMSClassUnloadingEnabled :( only UseConcMarkSweepGC be useful in the case also enabled) is enabled when using the uninstall feature class CMS garbage collection mechanism. The default setting is not enabled, if you enable CMSClassUnloadingEnabled, the garbage collector will clean up the permanent generation, removed classes no longer in use.
-XX: + PrintGCDateStamps -verbose: gc, GC detailed information is printed on the log in
Generally, the style according to the following settings:
And introduce more parameters, please refer to: