How can I tune the G1 GC for this SOLR instance that creates a lot of short lived objects?

Hello Alex,

The settings you've applied look reasonable, but here are some additional tips to fine-tune it further:

1) Your application is suffering from long-running GC events. 76GC events took more than 5.0 seconds. Long running GCs are unfavorable for the application's performance. Please read this article to reduce long GC pauses.

2) Consider adjusting -XX:MaxGCPauseMillis=250. If you're experiencing frequent stop-the-world pauses, increase this value slightly to allow the collector more time to clean.

3) -XX:ConcGCThreads=2 and -XX:ParallelGCThreads=8 might need adjustment based on your workload and machine configuration. These settings control the number of concurrent GC threads and the number of parallel GC threads.

4) Increase -XX:G1NewSizePercent. By default, 5% of the heap is allocated to the young generation. Increase this to 20% or 30% to provide more space for short-lived objects before they are promoted to the old generation and potentially collected in full GCs.

5) Set -XX:G1MaxNewSizePercent. This parameter limits the maximum size of the young generation. Set it to a value slightly higher than -XX:G1NewSizePercent to prevent excessive young generation growth and trigger frequent GCs.

Hello Alex!

 Greetings. Did you saw the recommendations given by the GCeasy tool for your application? Can you try these recommendations?

• 1 hr 14 min 53 sec of GC pause time is triggered by 'G1 Evacuation Pause' event. This GC is triggered when copying live objects from one set of regions to another set of regions. When Young generation regions are only copied then Young GC is triggered. When both Young + Tenured regions are copied, Mixed GC is triggered..
  
  Solution:
  1. Evacuation failure might happen because of over tuning. So eliminate all the memory related properties and keep only min and max heap and a realistic pause time goal (i.e. Use only -Xms, -Xmx and a pause time goal -XX:MaxGCPauseMillis). Remove any additional heap sizing such as -Xmn, -XX:NewSize, -XX:MaxNewSize, -XX:SurvivorRatio, etc.
  
  2. If the problem still persists then increase JVM heap size (i.e. -Xmx).
  
  3. If you can't increase the heap size and if you notice that the marking cycle is not starting early enough to reclaim the old generation then reduce -XX:InitiatingHeapOccupancyPercent. The default value is 45%. Reducing the value will start the marking cycle earlier. On the other hand, if the marking cycle is starting early and not reclaiming, increase the -XX:InitiatingHeapOccupancyPercent threshold above the default value.
  
  4. You can also increase the value of the '-XX:ConcGCThreads' argument to increase the number of parallel marking threads. Increasing the concurrent marking threads will make garbage collection run fast.
  
  5. Increase the value of the '-XX:G1ReservePercent' argument. Default value is 10%. It means the G1 garbage collector will try to keep 10% of memory free always. When you try to increase this value, GC will be triggered earlier, preventing the Evacuation pauses. Note: G1 GC caps this value at 50%.