Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8131932

Ergonomics oversize number of GC threads for small JVMs on large systems


    • Type: Enhancement
    • Status: Open
    • Priority: P3
    • Resolution: Unresolved
    • Affects Version/s: 8
    • Fix Version/s: tbd
    • Component/s: hotspot
    • Subcomponent:


      Description from filer:

      We are running a small Java-based monitoring agent for performance monitoring of a database on an M7 system with 2688 cpus. The JVM is configured with a 2 GB heap. Per default, the JVM creates 1682 parallel GC threads. It seems, HotSpot Ergonomics are purely based on the cpu count of the system, but not the JVM size. Such a large number of GC threads is completely unreasonable for a JVM with only 2 GB of Java heap.

      As a result, young GC times are in the range of about 3 seconds, with 4000 (!) cpu seconds consumed per GC. When manually configuring the number of GC threads to 64, GC times are reduced to around 0.05 seconds with 1-2 cpu seconds consumed.

      On average, this JVM only consumes about half a cpu (out of 2688 cpus) when using 64 GC threads, and its garbage collections have no effect on the overall system. However, with the default of 1682 GC threads, the spikes in CPU utilization during garbage collection drive overall cpu utilization from 20% (average) to 80% (peak), heavily disturbing the database running on this system.

      Many Java applications aren't meant for highest performance, but only provide supplementary tasks (such as this monitoring agent). Java Ergonomics should come up with a reasonable default sizing of these JVMs. The total configured Java heap size could serve as an indication as to how many GC threads may at most be necessary.


          Issue Links



              • Assignee:
                shadowbug Shadow Bug
              • Votes:
                1 Vote for this issue
                8 Start watching this issue


                • Created: