Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Elastic JVM: Automatic Vertical Scaling of the Java Heap

4.027 visualizaciones

Publicado el

Containers provide much better elasticity and density than VMs, but JVM-based applications are not fully container-ready. The first issue is that HotSpot JVM doesn’t release unused committed heap memory automatically. Second, it is not possible to increase the size of the JVM heap at runtime. To solve these two major issues and make JVM more container-friendly, a new patch is implemented for the Garbage-First collector in OpenJDK 9. This presentation shares details of what is done and how the added improvements enhance resource consumption efficiency.

From the session at Oracle Code One 2018 presented by Ruslan Synytsky, Jelastic CEO.

Publicado en: Tecnología
  • I can advise you this service - ⇒ ⇐ Bought essay here. No problem.
    ¿Estás seguro?    No
    Tu mensaje aparecerá aquí
  • There is a useful site for you that will help you to write a perfect and valuable essay and so on. Check out, please ⇒ ⇐
    ¿Estás seguro?    No
    Tu mensaje aparecerá aquí

Elastic JVM: Automatic Vertical Scaling of the Java Heap

  1. 1. Elastic JVM Automatic Vertical Scaling of the Java Heap
  2. 2. Java Can Be Greedy!
  3. 3. Java Memory Consumption Problems
  4. 4. Java Memory Consumption Problems Difficult to Scale Costs Too Much Consumes a Lot
  5. 5. Technical Reasons to Make Java Flexible
  6. 6. Horizontal Scaling Is Not Always a Solution
  7. 7. Better Elasticity & Density with Containers
  8. 8. Reducing Memory Usage to Speed Up Live Migration
  9. 9. Overpayment for Java Cloud Hosting
  10. 10. Pay per Usage as for Electricity
  11. 11. Reserved vs Consumed Real statistics of defined limits and actually consumed resources Wasted Resources Used Resources
  12. 12. Are JVM-Based Applications Fully Container-Ready?
  13. 13. Blockers for JVM Automatic Vertical Scaling Unreleased Heap Memory Restart for Xmx Resize
  14. 14. Garbage Collectors Testing
  15. 15. G1 Garbage Collector: Fast Memory Usage Growth java -XX:+UseG1GC -Xmx2g -Xms32m -jar app.jar 0 Memory grew from 32 MB to 1 GB in 25 seconds
  16. 16. G1: Medium Memory Usage Growth java -XX:+UseG1GC -Xmx2g -Xms32m -jar app.jar 10 Memory grew from 32 MB to 1 GB in 90 seconds during 4 cycles
  17. 17. G1: Slow Memory Usage Growth java -XX:+UseG1GC -Xmx2g -Xms32m -jar app.jar 100 Memory grew from 32 MB to 1 GB with delta time growth of about 300 seconds
  18. 18. G1: Aggressive Heap = No Vertical Scaling java -XX:+UseG1GC -Xmx2g -Xms2g or java -XX:+UseG1GC -Xmx2g -XX:+AggressiveHeap
  19. 19. Parallel Garbage Collector java -XX:+UseParallelGC -Xmx2g -Xms32m -jar app.jar 10 The unused but committed RAM is never released back to OS
  20. 20. Serial Garbage Collector java -XX:+UseSerialGC -Xmx2g -Xms32m -jar app.jar 10 It requires 4 Full GC cycles to release all unused resources
  21. 21. ConcMarkSweep Garbage Collector java -XX:+UseConcMarkSweepGC -Xmx2g -Xms32m -jar app.jar 10 It requires 4 Full GC cycles to release all unused resources
  22. 22. Calling Full GC On-Time 1. Full GC is not triggered automatically and must be executed explicitly 2. Can lead to significant performance degradation Workaround: inject an agent which monitors the memory usage and calls System.gc() periodically: -javaagent:jelastic-gc-agent.jar=period=300,debug=true
  23. 23. Shenandoah Garbage Collector java -Xmx2g -Xms32m -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC -XX:ShenandoahUncommitDelay=1000 -XX:ShenandoahGuaranteedGCInterval=10000 -jar app.jar 10 It releases unused RAM back to OS on the fly without Full GC calls
  24. 24. The Z Garbage Collector java -XX:+UnlockExperimentalVMOptions -XX:+UseZGC
  25. 25. OpenJ9 Command-line options to enable automatic vertical scaling: ● -XX:+IdleTuningGcOnIdle ● -XX:+IdleTuningCompactOnIdle ● -XX:IdleTuningMinIdleWaitTime=<secs> ● Low memory footprint ● Fast startup time ● High application throughput ● Smoother ramp-up in the cloud
  26. 26. New Patch for Garbage-First Collector in OpenJDK 9
  27. 27. Started in 2011 ● Initiated investigation (at first, worked out only with SerialGC) ● Built cloud business model on vertical scaling ● Started to promote in the community
  28. 28. Credits To ● Ruslan Synytsky, Tetiana Fydorenchyk: Jelastic ● Rodrigo Bruno, Paulo Ferreira: INESC-ID / Instituto Superior Técnico, University of Lisbon ● Jia Rao: The University of Texas at Arlington ● Hang Huang, Song Wu: Huazhong University of Science and Technology ● Thomas Schatzl: Oracle
  29. 29. Timely Reduce Unused Committed Memory Make the G1 garbage collector automatically give back Java heap memory to the operating system when idle ● G1PeriodicGCInterval ● G1PeriodicGCSystemLoadThreshold ● G1PeriodicGCInvokesConcurrent
  30. 30. Dynamic Max Memory Limit Allow a user to increase / decrease the amount of Java heap memory available to the application at runtime jinfo -flag CurrentMaxHeapSize=1g <java_pid>
  31. 31. Extra Tips Not to Lose Your Memory
  32. 32. Improving Memory Compaction -XX:-ShrinkHeapInSteps ● disable 4 full GC cycles ● release unused RAM resources faster ● minimize the Java heap size usage in applications with variable load
  33. 33. Tracking Native Non-Heap Memory Usage -XX:NativeMemoryTracking=summary 5-10% performance hit if this option is enabled
  34. 34. Java SE Support for Docker CPU and RAM Limits CPU (Java SE 8u131+) -XX:ParalllelGCThreads or -XX:CICompilerCount if not specified → Docker CPU limit RAM Java heap via -Xmx if not specified → -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap mits-in-containers-lxc-docker-and-openvz /java-se-support-for-docker-cpu-and-memor y-limits
  35. 35. Make Your Java Elastic Learn More Get In Touch