JVM memory partitioning

Heap allocation

  • Initial heap memory allocation:-Xms, the default is 1/64 of physical memory;
  • Maximum heap memory allocation:-Xmx, the default is 1/4 of physical memory.

When the default free heap is less than 40%, the JVM increases the heap to the maximum limit of -xmx; When free heap memory is greater than 70%, the JVM reduces the heap to the minimum limit of -xMS. So servers typically set -xms, -xmx equal to avoid resizing the heap after each GC.

Non-heap memory allocation

  • Non-heap memory initial allocation:-XX:PermSize, the default is 1/64 of physical memory;
  • Non-heap maximum memory allocation:-XX:MaxPermSize, the default is 1/4 of physical memory.

Description:

  1. If the -xmx don’t specify or specify slants small, application may result in Java. Lang. An OutOfMemoryError.

  2. If – XX: MaxPermSize set starts to result in Java. Lang. OutOfMemoryError: PermGen space is profit out of memory.

Why does memory benefit?

  • This part of memory is used for storageClassandMetaThe information,ClassIt’s put in when it’s loadedPermGen spaceArea, it and storageInstanceThe Heap area is different.
  • Garbage Collection (GC) does not collect data during the main program runtimePermGen spaceSo if your APP is going to LOAD a lot of classes, it’s probably going toPermGen spaceError. This error is common on Web servers with JSPSpre compileFrom time to time.

JVM Parameters

The JVM parameter instructions
-server Be sure to use it as the first parameter to perform well on multiple cpus
-Xms Initial Java Heap size. The default is 1/64 of physical memory.
-Xmx Maximum Number of Java Heap. You are advised to set the memory size to half of the physical memory. Cannot exceed physical memory.
-Xmn The heap size of young generation is generally set to 3 or 4 times that of Xmx
-XX:PermSize Set the initial size of the permanent memory area. The default value is 64 MB.
-XX:MaxPermSize Set the maximum permanent memory size. The default value is 64 MB.
-XX:SurvivorRatio The size of the survivor pool is 2 by default, and you can try customizing the build pool Settings if garbage collection becomes a bottleneck
-XX:NewSize The initial size of the newly generated pool. The default value is 2M.
-XX:MaxNewSize The maximum size of the newly generated pool. The default value is 32 MB. If the JVM heap size is greater than 1GB, the value should be: -xx :newSize= 640M-XX :MaxNewSize= 640M-XX :SurvivorRatio=16, or 50% to 60% of the total heap size should be allocated to the newly generated pool. Increase new object area to reduce Full GC times.
-XX:+AggressiveHeap Makes Xms meaningless. This parameter causes the JVM to ignore the Xmx parameter and frantically eat up one gigabyte of physical memory and one gigabyte of swap.reference
-Xss Stack size per thread, “-xSS 15120” this causes JBoss to immediately consume 15M of memory for each additional thread (thread), and the optimal value should be 128K, the default seems to be 512K.
-verbose:gc Real garbage collection information
-Xloggc:gc.log Specify garbage collection log files
-XX:userParNewGC Set up parallel collection
-XX:+UseSerialGC Serial collectors are used in the new generation and the old generation
-XX:+UseParNewGC Use parallel collectors in the new generation to shorten minor’s collection time
-XX:+UseParallelGC The new generation uses the parallel collector, focusing more on throughput
-XX:+UseParallelOldGC The old days used parallel collection collectors
-XX:ParallelGCThreads Set the number of threads used for garbage collection
-XX:+UseConcMarkSweepGC The new generation uses parallel collectors, while the old generation uses CMS+ serial collectors
-XX:ParallelCMSThreads Set the number of threads in the CMS
-XX:+UseG1GC Enable the G1 garbage collector

For details, see the file of Tomcat Catalina.

JAVA_OPTS="-server -Xms1024m -Xmx8192m -XX:PermSize=256M -XX:MaxPermSize=1024m -Dfile.encoding=utf-8"
Copy the code

Speaking at the end

Another consideration is the garbage collection mechanism provided by Java. The heap size of a virtual machine determines how much time and frequency the virtual machine spends collecting garbage.

The acceptable speed of garbage collection depends on the application and should be adjusted by analyzing the timing and frequency of actual garbage collection. If the heap size is large, complete garbage collection is slow, but less frequent. If you align the heap size with memory requirements, full collections are fast, but more frequent.

The purpose of resizing the heap is to minimize garbage collection time in order to maximize the processing of customer requests at a given time. When benchmarking, for best performance, keep the heap size large to ensure that garbage collection does not occur throughout the benchmark.

If your system is spending a lot of time collecting garbage, reduce the heap size. A complete garbage collection should take no more than 3-5 seconds. If garbage collection becomes a bottleneck, you need to specify the size of the generation, examine the verbose output of garbage collection, and investigate the impact of garbage collection parameters on performance.

In general, you should use 80% of physical memory for the heap size. When adding processors, remember to add memory because allocation can be done in parallel and garbage collection is not.

PS: Here is the configuration of my IDEA after it is tuned for Java development:

-Xms2048m
-Xmx3072m
-XX:NewRatio=3
-Xss16m
-XX:+UseConcMarkSweepGC
-XX:+CMSParallelRemarkEnabled
-XX:ConcGCThreads=4
-XX:ReservedCodeCacheSize=240m
-XX:+AlwaysPreTouch
-XX:+TieredCompilation
-XX:+UseCompressedOops
-XX:SoftRefLRUPolicyMSPerMB=50
-Dsun.io.useCanonCaches=false
-Djava.net.preferIPv4Stack=true
-XX:+HeapDumpOnOutOfMemoryError
-XX:-OmitStackTraceInFastThrow
-Dfile.encoding=utf-8
Copy the code

Reference:

  • Tomcat memory configuration and configuration parameters
  • Tomcat memory configuration for memory overflow
  • Java GC mechanism