4.16.2013

I have
been receiving recently many comments and emails related to Minecraft Java related errors such as java.lang.NullPointerException. I recommend to look at the following YouTube video:

While this Blog is dedicated to general Java and
Java EE troubleshooting, I’m still willing to help non Java programmers and
Minecraft gamers who are facing these problems such as
java.lang.NullPointerException when developing Mods.

If you are
in fact facing such problem, please follow the steps below:

4.15.2013

The
following question will test your knowledge on garbage collection and high CPU
troubleshooting for Java applications running on Linux OS. This troubleshooting
technique is especially crucial when investigating excessive GC and / or CPU
utilization.

It will assume
that you do not have access to advanced monitoring tools such as Compuware dynaTrace or even JVisualVM. Future tutorials using such tools will be
presented in the future but please ensure that you first master the base
troubleshooting principles.

Question:

How can
you monitor and calculate how much CPU % each of the Oracle HotSpot
or JRockit JVM garbage collection (GC) threads is using at runtime on Linux OS?

Answer:

On the
Linux OS, Java threads are implemented as native Threads, which results in each
thread being a separate Linux process. This means that you are able to monitor
the CPU % of any Java thread created by the HotSpot JVM using the top –H command (Threads
toggle view).

That said,
depending of the GC policy that you are using and your server specifications, the HotSpot & JRockit JVM
will create a certain number of GC threads that will be performing young and
old space collections. Such threads can be easily identified by generating a JVM
thread dump. As you can see below in our example, the Oracle JRockit JVM did create 4 GC
threads identified as "(GC Worker Thread X)”.

At the same
time of Linux top –H, generate 2 or 3 JVM Thread Dump snapshots via kill -3
<Java PID>.

Open the JVM Thread Dump and locate the JVM GC
worker threads.

Now correlate the "top -H" output data with the JVM Thread Dump data by
looking at the native thread id (tid attribute).

As you can
see in our example, such analysis did allow us to determine that all our GC
worker threads were using around 20% CPU each. This was due to major
collections happening at that time. Please note that it is also very useful to
enable verbose:gc as it will allow you to correlate such CPU spikes with
minor and major collections and determine how much your JVM GC process is contributing to the overall server CPU utilization.