Skip to content

JVM

Martini Server Runtime is configured to run using Apache Tomcat, a Java Servlet Container. Tomcat, in turn, runs on top of a Java Virtual Machine (JVM).

While a generic JVM configuration may be suitable, it's recommended to tailor your JVM settings based on your organization's usage of Martini Server Runtime. This guide will discuss the various JVM configuration options that can help, directly or indirectly, to improve Martini Server Runtime's performance.

Tuning the JVM requires a thorough understanding of Java and JVM memory management. The individual responsible for JVM tuning should possess expertise in the production environment and JVM internals. Attempting to tune without this knowledge can have adverse effects on performance.

Understanding JVM Garbage Collection and Heap

The JVM utilizes a memory management tool known as the garbage collector (GC), which frees up unused Java objects in the heap. The heap is divided into two crucial parts: the young generation and the old generation.

The young generation is where new objects are allocated and aged. When it fills up, a minor garbage collection occurs. Objects with longer lifespans move to the old generation, triggering major garbage collection eventually.

Two key factors influencing garbage collection performance are:

  • Total available memory: Increasing memory allocation can reduce frequency of collections but may lead to longer pauses.
  • Proportion of heap dedicated to young generation: A larger young generation reduces minor collections but may increase major collections' frequency.

Tuning the Java Heap

Boosting Martini Server Runtime's performance often involves adjusting heap size. However, allocating more memory increases GC workload. Optimal heap size balances GC time and application execution time.

Configure heap size using:

  • -Xms<size>: Initial and minimum heap size.
  • -Xmx<size>: Maximum heap size.

For instance:

1
java -Xms2g -Xmx2g Martini

Note that setting -Xms and -Xmx equally enhances performance, preventing JVM from spending time incrementing heap allocation.

Optimizing JVM Garbage Collection

When increasing memory allocation isn't viable, optimizing garbage collection can improve pause times or event frequency. This involves:

  1. Selecting suitable garbage collector based on production environment.
  2. Profiling results to evaluate effectiveness.

Choosing the Right Garbage Collector

Consider application requirements to choose between throughput-oriented and low-pause collectors.

Throughput-Oriented Collectors

  • Serial Collector: Single-threaded, suitable for smaller datasets or single-processor machines.
  • Parallel Collector: Utilizes multiple threads for minor collections, beneficial for medium to large datasets on multi-processor machines.

Low-Pause Collectors

  • Concurrent Mark-and-Sweep Collector: Cleans concurrently with application, minimizing pauses.
  • Garbage-First (G1) Collector: Default in Java 9, aims to replace CMS GC.

Profiling Results

  • Profile Martini Server Runtime to assess chosen configuration's suitability.
  • Ensure controlled testing environment and realistic scenarios.
  • Analyze garbage collection logs for insights.

Testing Procedure

  1. Determine production environment requirements.
  2. Select suitable garbage collector.
  3. Configure garbage collector.

  4. Enable garbage collector logging. This can be as simple as using the JVM option:

    1
    -XX:+PrintGCDetails-XX:+PrintGCDateStamps-XX:+PrintGCTimeStamps -Xloggc:gclog.log
    5. Conduct tests mimicking real-world scenarios. 6. Analyse garbage collection logs. 7. Iterate based on results.

Example

A test case comparing JVM arguments -Xms1g -Xmx1g and -Xms2g -xmx2g demonstrates minimal difference. Real-world scenarios may have varying outcomes.

Additional Resources

Refer to these links for further JVM optimization: