Have you ever encountered circumstance in which your apps CPU maxes out and in no way goes down even if targeted visitors volume goes down? Did you had to recycle to JVM to remediate the challenge? Even if you recycle the JVM, does your CPU get started to spike up immediately after some time?
This style of challenge surfaces because of a single of the pursuing reasons:
Recurring Full GC
non-synchronized entry to java.util.HashMap
Let’s see how to diagnose these situations and address them.
Situation 1: Repeated Comprehensive GC
Whole GC is an critical stage of Rubbish Collection approach. In the course of this stage, complete JVM is frozen, each one object in the memory is evaluated for garbage collection, normally, it turns out to be a CPU intense operation. If application occurs to have memory leak, then “Whole GC” will get started to operate repeatedly without having reclaiming any memory. When ‘Full GC’ runs continuously, CPU will get started to spike up and in no way appear down.
Tactical Answer: To take care of the trouble entirely, memory leak in the software has to be fixed. Resolving memory leaks could possibly take some time. (Of study course it goes with no expressing, you can engage experts like me.to resolve it speedily). Until finally then under described tactical solution can be implemented to preserve the software operating in creation. You require to instrument a script which would keep track of rubbish collection log file of the software for every 2 minutes. If the script notices far more than 3 ‘Full GC’ runs in a 10-moment window, then that distinct JVM need to be decommissioned from getting manufacturing site visitors. JVM should be recycled right after capturing thread dump and heap dump. Soon after recycling JVM should really be positioned back to choose energetic traffic.
Strategic Alternative: Applying the Heap Dump/Thread Dump root cause of the difficulty ought to be identified & mounted.
Scenario 2: non-terminating loops
Often thanks to bug in your code or in the 3rd get together library that you use – loop constructs (even though, for, do.although) may well operate eternally. Look at the circumstance down below:
Due to sure facts condition or bug in the code, ‘myCondition’ may never get satisfied. In this sort of circumstance, thread would be spinning infinitely in the even though loop. This would trigger the CPU to spike up. Except JVM is restarted, CPU maxing out wouldn’t quit at all.
Alternative: When you notice CPU maxing out and utilization not coming go down, you must just take 2 thread dumps in a hole of 10 seconds amongst every single thread dump – correct when problem is occurring. Each individual thread in “runnable” state in the initial taken thread dump must be mentioned down. Similar threads state in the next thread dump should really be when compared. If in the second thread dump also those threads continue to be the runnable state inside of the identical technique, then it would indicate in which element of the code thread(s) are looping infinitely. At the time you know which section of the code is looping infinitely then it must be trivial to address the dilemma.
Circumstance 3: non-synchronized obtain of java.util.HashMap
When several threads tries to accessibility HashMap’s get() and place() APIs concurrently it would induce threads go into infinite looping. This problem does not happen always, but almost never it does transpires.
Alternative: When you observe CPU maxing out and utilization not coming go down, you ought to get a thread dump – proper when challenge is happening. You need to have to see which are threads that are in “runnable” state. If that thread occurs to be operating on HashMap’s get() or set() API, then it can be indicative that HashMap is causing CPU spike. Now you can exchange that HashMap with ConcurrentHashMap.