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

https://www.infoq.com/presentations/jvm-60-memory/
The Trouble with Memory (Page last updated September 2019, Added 2019-10-29, Author Kirk Pepperdine, Publisher QCon). Tips:

• Excessive memory churn is a hugely common application bottleneck (because of the speed difference between CPU and memory fetches), but it's not well monitored so it's often not identified. GC logs produce fairly good data
• Reducing memory churn (eg by code changes, reduced logging) can improve application throughput dramatically
• Target hot allocation sites in the code to identify where memory churn is being caused
• High memory churn rates quickly fills the young generation which causes frequent GCs and more copying, faster aging so faster promotion, and more frequent tenured cycles
• Rule of thumb allocation rates - above 1GB/sec is a problem, below 300MB/sec is okay
• Profilers can interfere with the JVM optimizers, eg an object escaped by the JIT compiler can be stopped from being escaped because the profiler is tracking the object.

https://www.youtube.com/watch?v=yUVwJ_n5EeQ
HotSpot Performance Case Study (Page last updated September 2019, Added 2019-10-29, Author Sergey Kuksenko, Publisher Oracle). Tips:

• Run-to-run variance is a problem for repeated measurements. Minimize it by: turning off anti-viruses, shutting down browsers, use consistent execution scripts, ensure the OS is stable and it's network dependencies are not changing, turn off power management that changes the CPU frequency, set the cpu frequency to the standard one for the CPU as turbo-boost is unpredictable (cpufreq-set), use non-tiered compilation TieredCompilation has higher variance, GC can cause significant variance check the GC logs.
• If you are measuring when the application is not in it's steady state, you need to consider all the data for the whole run (rather than just the steady state data).
• If possible, repeat the execution until steady state (no more JIT compilation) is achieved, and GC is consistent.
• Use what you know to validate what you see, eg a single-threaded CPU bound application should fully use one core.
• Instructions per clock cycle is an interesting metric to look at - to decrease execution time you need to decrease either the number of instructions (algorithm) or the instructions executed per clock cycle (CPU stalls). 2 instructions executed per clock cycle is a good number to achieve.

https://www.youtube.com/watch?v=OG0K1srtgIM
Fantastic Performance and where to find it (Page last updated July 2019, Added 2019-10-29, Author Richard Warburton, Publisher Devoxx). Tips:

• A profiler is finding the main consumer of a resource, eg CPU time (CPU resource), Wall clock time (customer resource), Memory.
• The first place to start when profiling is raw OS metrics, eg from vmstat.
• Profiling CPU execution is mostly straightforward - find the methods that take up most of the CPU time. Blocking bottlenecks (bottlenecks that make your application wait for something) can be found by looking at wall clock times. These are often bottlenecked on locks or IO.
• Realistic workloads have the same load and distribution request as production, with the system running on the same type of hardware. The production system itself is the ideal system to test on. Using low overhead profiling on production systems is the ideal way to profile. Open source low overhead profilers include async-profier, honest profiler, perf + perf-mapper-agent, flight recorder, solaris studio (works fine on Linux).
• Intermittent issues are very difficult to analyse, the ideal solution is to record performance data all the time so that you capture the data during the issues as they happen, rather than trying to reproduce them.

https://vimeo.com/showcase/5419780/video/291453280
Threads in JVM: managing, observing and diagnosing (Page last updated September 2018, Added 2019-10-29, Author Adam Dubiel, Publisher JavaZone). Tips:

• JVM threads are system threads, so the OS sees and schedules them. OS tools show the native threads, and in the JVm context jstack or jcmd Thread.print shows the threads including the native thread ID, nid, (the ID that the OS has)
• Thread.setName() has a 15 character limit, but from Java 9+ it propagates that to the OS thread name (prior to Java 9, Thread.setName() did nothing for the OS level thread name).
• Costs of threads include: thread stack memory (1MB by default), context switching overheads, safepointing overheads, GC overheads
• -XX:NativeMemoryTracking=summary -XX:+PrintNMTStatistics lets you look at thread native memory statistics
• Virtual set size (VSZ) shows what you want the OS to provide you, but nor what it is actually using in real memory. Resident set size (RSZ or RES) shows the real memory being used on the hardware. Asking for memory (like creating a thread) but not doing anything with it leaves the memory in VSZ so leaving lots of memory available in RSZ.
• A context switch typically requires the CPU caches being filled from main memory to get the data for the newly running thread and will take many microseconds.
• Thread pools by default are unbounded - either in the number of threads or in the size of the queue for tasks queueing for a limited size thread pool. The non-default thread pool constructor let's you bound the pool size, the queue size, and provide a task rejection policy for when the queue is full.
• You can pre-warm thread pools by telling them to create all core threads
• You can log thread pools by eg -Xlog:thread+os:file=/tmp/threads.log

Jack Shirazi Back to newsletter 227 contents