JProfiler Get rid of your performance problems and memory leaks! Modern Garbage Collection Tuning Java Performance Training Courses COURSES AVAILABLE NOW. We can provide training courses to handle all your Java performance needs Java Performance Tuning, 2nd ed The classic and most comprehensive book on tuning Java Java Performance Tuning Newsletter Your source of Java performance news. Subscribe now! Enter email: Training online Threading Essentials course JProfiler Get rid of your performance problems and memory leaks!

Back to newsletter 283 contents

https://medium.com/@AlexanderObregon/writing-scalable-java-applications-best-practices-and-strategies-718a338e41c0
Writing Scalable Java Applications: Best Practices and Strategies (Page last updated November 2023, Added 2024-06-30, Author Alexander Obregon, Publisher Medium). Tips:

• Scalability is handling increased loads without compromising performance - serving more requests but doing so efficiently and reliably. Scalability can be achieved vertically (adding more resources to a single node) and horizontally (by adding more nodes to a system). Horizontal scaling is often preferred for its benefits in availability and fault tolerance.
• Some architectural practices that assist scaling are: decomposing systems into modular units that provide specific subsets of services, to scale these independently (eg microservices); Loose coupling eg with event-driven request flows; and containerization.
• Asynchronous handling such as with reactive systems supporting backpressure improves the ability to scale.
• Efficient memory management is vital for scaling components: eliminate memory leaks, use appropriate data structures, and optimize garbage collection both within code and by choosing and tuning the garbage collector.
• Effective management of concurrency is critical for scalability: Use java.util.concurrent data structures and control mechanisms, manage threads efficiently, and prefer immutable objects.
• Regular profiling and optimization helps maintain scalability: Identify and optimize code bottlenecks.
• Tune the JVM: Adjust the heap size - more memory can reduce the frequency of garbage collections, but too much can lead to wasted resources and long GC pauses; Choose and tune the garbage collector;.
• Cache effectively. Choose between local and distributed caches appropriately for the data and request types, and ensure the cache invalidation strategies provide an efficient cache-hit ratio.
• Efficient database interaction usually involves connection pooling and optimized queries, as well as optimizing the database structure for the application's update and access patterns.
• Effective monitoring is crucial for understanding and improving performance: Ensure the system has Application Performance Monitoring, Logging frameworks, Logs analysis tools, collects metrics and performs health checks.

https://www.youtube.com/watch?v=ZKe4jGe1sL4
Memory settings for Java process running in Kubernetes pod (Page last updated August 2023, Added 2024-06-30, Author Fan Liu, Publisher Medium). Tips:

• There is no way to guarantee the complete memory boundary of a Java process since the JVM respects only the heap size limit, not non-heap memory. The non-heap memory is difficult to predict as it depends on multiple factors (code generation, thread counts, GC algorithm, number of classes loaded, etc).
• A container will be killed (by the OOM Killer) if the native memory used exceeds the container memory limit. Because the JVM uses a variable amount of memory, and only the heap memory is constrained, you need to ensure that the JVM heap limit is sufficiently below the container limit that the JVM non-heap memory usage doesn't make the container native memory usage go above the limit.
• It is important to note that the -XX:MaxRAMPercentage does NOT constrain the total size of the memory the Java process can use. It specifically refers to the JVM heap size.
• Committed memory is that part of system memory that the JVM has already allocated. The Xms heap memory is committed at start, and that raises up to Xmx as the JVM+application needs. Some garbage collectors can return committed memory if it's no longer needed in the heap, but the heap usage can be much less than the committed memory unless that happens.
• The suggested procedure for setting container JVM memory is: 1. start with MaxRAMPercentage at 75%; 2. If your maximum heap usage stays high, you need to increase the container memory, but if the heap usage is okay but the process size is close to the container limit, you need to decrease MaxRAMPercentage (or give more container memory).

https://medium.com/codex/running-jvm-applications-on-kubernetes-beyond-java-jar-a095949f3e34
Running JVM Applications on Kubernetes: Beyond java -jar (Page last updated February 2024, Added 2024-06-30, Author Thiago Mendes, Publisher CodeX). Tips:

• JVM GC choice (if no explicit GC algorithm flag is set): If the number of CPUs is equal to or greater than 2 and the amount of memory is greater than 1792MB, the chosen GC will be the G1 GC (or ParallelGC before Java 9). If either of these two conditions is below the mentioned values, the chosen GC will be the SerialGC.
• When -Xmx is not set, the JVM configures maximum heap value as a quarter of the available (container) memory, unless below 256MB is available when the maximum heap value will be 50%, or between 256MB and 512MB is available when the maximum heap value will be approximately 127MB.
• To find out which GC implementation your JVM is using, execute java -XX:+PrintFlagsFinal -version | grep "Use" | grep "GC" (or findstr instead of grep on Windows). Similarly filtering for "MaxHeapSize" will show you what the Xmx value is.
• Avoid using SerialGC in high-concurrency apps by ensuring that the JVM is not limited to only 1 available CPU. If necessary set the -XX:ActiveProcessorCount flag with values greater than 1, but note that a discrepancy between the actual available CPU and the value provided could lead to inefficiencies in the JVM.
• Specify the desired GC implementation. One simple recommendation is to use ParallelGC for heaps up to 4GB and G1 for heaps above 4GB. Options include -XX:+UseSerialGC / -XX:+UseParallelGC / -XX:+UseG1GC / -XX:+UseShenandoahGC / -XX:+UseZGC.
• It's best to use containers 2000m CPU limits or more. It's usually better to have a single JVM in a container with a 2000m CPU limit than two separate JVMs in two containers with 1000m CPU limits.
• It's better to explicitly configure the JVM heap size using the -Xmx parameter or the -XX:MaxRAMPercentage, than leaving it to the JVM to choose a value.
• JVM memory areas include heap and non-heap (native memory/off-heap). Included within the non-heap are Metaspace, Code Cache, Stack Memory, GC Data, and others. Consequently you should configure the heap size of your JVM between 50% and 75% of available memory, reserving the remaining value for non-heap and the operating system.
• Use load testing to validate that the configured heap size is suitable for your application, checking for occurrences of OOM (including from the OOM killer).
• Set Xms equal to the value of Xmx if you want to avoid the JVM having to deal with memory allocation and deallocation tasks. But this means JVM process size will never be minimized.
• For Kubernetes containers, use memory request equal limit. If your JVMs will have non-synchronized processing, then use burstable containers (CPU limits bigger than requests) to let the JVMs use spare CPU resources that other containers are not concurrently using.
• Horizontal Pod Autoscaling based on CPU can work for JVMs because higher load JVMs typically generate many more objects and so use much more GC which is CPU intensive.

Jack Shirazi Back to newsletter 283 contents