This chapter contains the following sections:
Set up the Java environment and command-line options to enable gathering relevant data for troubleshooting.
To set up Java, perform the following:
Set up JVM options and flags to enable gathering relevant data for troubleshooting.
The data you gather depends on the system and what data you would use in case you run into problems. Consider gathering the following data.
ulimit -c unlimitedbefore starting the application command. Some systems may have different ways to handle these limits.
Note:The core files take up a lot of disk space, especially when run with a large Java heap.
To decide whether to enable core files, consider what you would do if you had a crash in your system. Would you want to see a core file? Many Java users won't have much use for a core file. However, if you would want to debug a possible crash either in a native debugger such as
gdb or by using the Serviceability Agent, then ensure that you enable core files before the starting the application.
Many times, crashes are hard to reproduce; therefore, enable core files before the starting the application.
-XX:+HeapDumpOnOutOfMemoryErrorflag saves a Java Heap dump to disk if the applications runs into an
Like core files, heap dumps can be very large, especially when run with a big Java heap.
Again, think about what you would do if the application runs into an
OutOfMemoryError. Would you want to inspect the heap at the time of the error? In that case, turn flag by default so that you get this data if the application runs into an unexpected
Set up Java to run with a continuous flight recording. Continuous flight recordings are a circular buffer of JFR events. If the application runs into an issue, you can dump the data from the last hour of the run. The JFR events can be helpful to debug a wide range of issues from memory leaks to network errors, high CPU usage, thread blocks, and so on.
The overhead of running with a continuous flight recording is very low. See How to Produce a Flight Recording for producing a continuous Java Flight Recording.
-verbosegclogs basic information about Java Garbage Collector. This log helps you find the following:
Does garbage collection run for a long time?
Does the free memory decrease over time?
The garbage collector log helps diagnose issues when the application throws an
OutOFMemoryError or the application runs into performance issues; therefore, turning on the
-verbosegc flag by default helps troubleshoot issues.
Note:Use log rotation so that an application restart doesn't delete the previous logs. Since JDK7, the flags
NumberOfGCLogFilescan be used to set up for log rotation. For a description of these flags, see Debugging Options for Java HotSpot VM.
If your application starts with a script, run
java -version to print the Java version and print the command line before executing it. Another alternative is to add
-showversion to the JVM arguments.
Another alternative, is to enable JMX after a Java application has started is to use the diagnostic command
jcmd <pid> help ManagementAgent.start for a list of flags that can be sent with the command.
See The jcmd Utility.
If your application runs into a problem and you want to debug the problem further, ensure that you collect any relevant data before restarting the system, especially if restarting will remove previous files.
Core files for crash issues.
hs_err printed text file for Java crashes.
Log files: Java and application logs.
Java heap dumps for
Java flight recordings (if enabled). If the problem didn't terminate the application, dump the continuous recordings.
Stack traces: Take several stack traces using
jcmd <pid> Thread.print before restarting the system.
Dump flight recordings (if enabled).
Force a core file: If the application can't be closed properly, then stop the application, and force a core file using
kill -6 <pid> on Linux or Solaris systems.