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 258 contents

https://medium.com/expedia-group-tech/an-exercise-in-software-resiliency-on-kubernetes-a241dd1c6f7b
An Exercise in Software Resiliency on Kubernetes (Page last updated April 2022, Added 2022-05-26, Author Sasidhar Sekar, Publisher Expedia). Tips:

• You need to monitor infrastructure deployment tools availability - if they are unavailable, any failures requiring redeployment will be impacted meaning your whole system could become unavailable.
• Connectivity issues are common in production and should be tested for.
• Unlimited retry can cause long delays in processing. Retry should be limited and fail fast enough for requests to be errored or failed over.
• Liveness and readiness are different tests, and you should use the appropriate test for the component that needs testing. Readiness is often the more useful test - if a component is not ready to handle requests, it shouldn't be sent requests. Liveness is a base level test which is easy to carry out, so is often used as a proxy for readiness, but it usually isn't and can lead to unresponsive systems that appear to be okay from a monitoring point of view.
• Component startup needs to be carefully considered, if it is not fast enough then what happens to requests and liveness and/or readiness checks during startup and what is the consequence of the tests failing during the startup phase - a restart loop could be one adverse consequence.
• Resilience to failure needs to be regularly tested.

https://dzone.com/articles/all-you-need-to-know-about-garbage-collection-in-j
All You Need To Know About Garbage Collection in Java (Page last updated August 2021, Added 2022-05-26, Author Aashish Patil, Publisher DZone). Tips:

• Objects are created in the heap; when new object allocation cannot proceed because the area of the heap the objects are being created in is full, a garbage collection happens. This reclaims the memory from dead objects and so frees up room to allow object allocation to proceed. Some heaps are divided into a young generation and an old generation, as most objects have short lives so can be collected quickly, with a faster but not fully accurate garbage collection in the young generation. Aged unreclaimed objects move to the old generation, and if that gets full a complete but more time consuming garbage collection is performed. This means that with two generation heaps, if you can keep your object lifecycle short, they will all be collected using the fast young generation collector, meaning less impact on the application.
• JVM process size can be calculated as: JvmProcessMemory = JVMHeap + Metaspace + CodeCache + (ThreadStackSize* Number-of-Threads) + DirectByteBuffers + Jvm-native-heap. Metaspace contains class metadata, there is no limit to metaspace size, unless limited with the MaxMetaspaceSize parameter. The thread stack size can be set with -Xss.
• If garbage collections happen too often or contribute to a significant percentage of CPU, either increase the Java heap size or reduce object allocation. -Xms sets the minimum and initial size; -Xmx sets the maximum size; -Xmn sets the size of the young generation.
• Test your applications under load to determine the maximum heap memory usage. Your production heap size should be 25%-30% higher than the tested maximum to allow room for overhead.
• Different garbage collectors are targeted at different application requirements: Serial for single processor machines or small heaps; Parallel for throughput; CMS (removed in JDK14) and G1 for low pause on resource constrained systems; ZGC and Shenandoah for even lower pauses on systems with a large amount of extra CPU and memory resources.
• You can analyze GC logs using one of the logs analyzers in http://www.fasterj.com/tools/gcloganalysers.shtml.

https://medium.com/miro-engineering/profiling-in-production-to-detect-server-bottlenecks-321919d2da51
Profiling in production to detect server bottlenecks (Page last updated May 2021, Added 2022-05-26, Author Sergey Peretyatko, Publisher Miro Engineering). Tips:

• There are always queues somewhere. Queue size is NOT a useful metric, since a non-empty queue does not imply a problem, in fact it could imply an efficient use of resources. Focus instead on the metrics that affect response time - median task wait time. The longest wait times are often anomalous - or may need to be targeted specifically depending on your application.
• For tasks that are dependent on calls out to external services, IO wait time typically dominates latency, so ensure that you monitor these.
• Take stack traces of anomalously long tasks - by monitoring task latency and triggering trace capture when they exceed thresholds.

Jack Shirazi Back to newsletter 258 contents