Basic GC Tuning

时间:2024-07-06 13:34:26

Sizing the Heap

  • -XmsN
  • -XmxN

Summary

  • The JVM will attempt to find a reasonable minimum and maximum 
    heap size based on the machine it is running on.
  • Unless the application needs a larger heap than the default, consider 
    tuning the performance goals of a GC algorithm (given in 
    the next chapter) rather than fine-tuning the heap size.

Sizing the Generations

  • -XX:NewRatio=N
    • Set the ratio of the young generation to the old generation.
    • default value of 2.
    • Initial Young Gen Size = Initial Heap Size / (1 + NewRatio) 
      • By default, then, the young generation starts out 
        at 33% of the initial heap size.
  • -XX:NewSize=N 
    • Set the initial size of the young generation.
    • If that option NewSize flag is set, it will take precedence over the value calculated fromthe NewRatio.
  • -XX:MaxNewSize=N 
    • Set the maximum size of the young generation.
    • By default, that maximum is also set using the 
      NewRatio value, though it is based on the maximum (rather than initial) heap size.
  • -XmnN 
    • Shorthand for setting both NewSize and MaxNewSize to the same value.
    • When a heap size is fixed (by setting -Xms equal to -Xmx),it is usually preferable to use -Xmn to specify a fixed size for the young generation as well.

Summary

  • Within the overall heap size, the sizes of the generations are 
    controlled by how much space is allocated to the young generation.
  • The young generation will grow in tandem with the overall heap 
    size, but it can also fluctuate as a percentage of the total heap 
    (based on the initial and maximum size of the young generation).

Sizing Permgen and Metaspace

  • When the JVM loads classes, it must keep track of certain metadata about those classes. 
    From the perspective of an end user, this is all just bookkeeping information. This data 
    is held in a separate heap space. In Java 7, this is called the permgen (or permanent 
    generation), and in Java 8, this is called the metaspace.
  • Permgen and metaspace are not exactly the same thing. In Java 7, permgen contains 
    some miscellaneous objects that are unrelated to class data; these are moved into the 
    regular heap in Java 8. As end users, all we need to know is that permgen/metaspace holds a bunch of class-related data, and that there are certain circumstances where the size of that region needs to be tuned.
  • Note that permgen/metaspace does not hold the actual instance of the class (the Class 
    objects), nor reflection objects (e.g., Method objects); those are held in the regular heap. 
    Information in permgen/metaspace is really only used by the compiler and JVM runtime, 
    and the data it holds is referred to as class metadata.
  • the metaspace rarely needs to be sized—because (unlike permgen) metaspace will by default use as much space as it needs.
  • These memory regions behave just like a separate instance of the regular heap. They are 
    sized dynamically based on an initial size and will increase as needed to a maximum size.
  • permgen, 
    • -XX:PermSize=N and -XX:MaxPermSize=N.
  • Metaspace 
    • -XX:MetaspaceSize=N and -XX:MaxMetaspaceSize=N.
  • Default maximum metaspace size Unlimited 
    • Because the default size of metaspace is unlimited, there is the possibility (particularly in a 32-bit JVM) that a Java 8 application can run out of memory by filling up metaspace.
  • Heap dumps can be used to diagnose what classloaders exist, which in 
    turn can help determine if a classloader leak is filling up permgen (or metaspace). 
    Otherwise, jmap can be used with the argument -permstat (in Java 7) or -clstats (in 
    Java 8) to print out information about the classloaders.

Summary

  • The permanent generation or metaspace holds class metadata (not class data itself). It behaves like a separate heap.
  • For typical applications that do not load classes after startup, the initial size of this region can be based on its usage after all classes have been loaded. That will slightly speed up startup.
  • Application servers doing development (or any environment where classes are frequently redefined) will see an occasional full GC caused when permgen/metaspace fills up and old class metadata is discarded.

Controlling Parallelism

  • All GC algorithms except the serial collector use multiple threads. The number of these 
    threads is controlled by the -XX:ParallelGCThreads=N flag. The value of this flag affects 
    the number of threads used for the following operations:
    • Collection of the young generation when using -XX:+UseParallelGC
    • Collection of the old generation when using -XX:+UseParallelOldGC
    • Collection of the young generation when using -XX:+UseParNewGC
    • Collection of the young generation when using -XX:+UseG1GC
    • Stop-the-world phases of CMS (though not full GCs)
    • Stop-the-world phases of G1 (though not full GCs)
  • Because these GC operations stop the application threads from executing, the JVM 
    attempts to use as many CPU resources as it can in order to minimize the pause time. 
    By default, that means the JVM will run one thread for each CPU on a machine, up to 
    eight. Once that threshold has been reached, the JVM only adds a new thread for every 
    five-eighths of a CPU. So the total number of threads (where N is the number of CPUs) 
    on a machine with more than eight CPUs is: 
    • ParallelGCThreads = 8 + ((N - 8) * 5 / 8)
  • Note that this flag does not set the number of background threads used by CMS or G1

Summary

  • The basic number of threads used by all GC algorithms is based 
    on the number of CPUs on a machine.
  • When multiple JVMs are run on a single machine, that number 
    will be too high and must be reduced.

Adaptive Sizing

  • The sizes of the heap, the generations, and the survivor spaces can vary during execution 
    as the JVM attempts to find the optimal performance according to its policies and 
    tunings.
  • This is a best-effort solution, and it relies on past performance: the assumption is that 
    future GC cycles will look similar to the GC cycles in the recent past. That turns out to 
    be a reasonable assumption for many workloads, and even if the allocation rate suddenly 
    changes, the JVM will readapt its sizes based on the new information.
  • At a global level, adaptive sizing is disabled by turning off the -XX:-UseAdaptiveSize 
    Policy flag (which is true by default). With the exception of the survivor spaces (which 
    are examined in detail in the next chapter), adaptive sizing is also effectively turned off 
    if the minimum and maximum heap sizes are set to the same value, and the initial and 
    maximum sizes of the new generation are set to the same value.

Summary

  • Adaptive sizing controls how the JVM alters the ratio of young 
    generation to old generation within the heap.
  • Adaptive sizing should generally be kept enabled, since adjusting 
    those generation sizes is how GC algorithms attempt to meet 
    their pause time goals.
  • For finely tuned heaps, adaptive sizing can be disabled for a small 
    performance boost.