1

I am using weblogic server and was trying to get the JFRs for my Weblogic Server. The command line arguments I use are:

-XX:FlightRecorderOptions=defaultrecording=true,dumponexit=true,dumponexitpath=/my/path,repository=/some/path

There are 2 disadvantages here:

1) There is a maximum of 3 JFRs stored and data before that are lost.

2) When there is an OOM, I execute a script to kill the server with signal 11 (SIGSEGV). This does not dump the currently recording JFR.

How do I go about getting the data at the time of crash and retain all the JFR data? Space is not an issue here. If I specify maxage=0, then the JFR is never dumped. If I specify maxsize, the files are deleted once the limit is reached.

Aswin Murugesh
  • 10,831
  • 10
  • 40
  • 69
  • I just found this question now, did you solve the problem or do you still need some help? – Klara May 17 '16 at 12:09
  • Thanks for your reply @Klara. We then wrote a script to copy the JFR files to another location, based on certain conditions of when we needed the file to be backed up. But, any outright solution to this is welcome. Please provide an answer – Aswin Murugesh May 18 '16 at 06:07
  • Did you try using -XX:FlightRecorderOptions=disk=true ? This will make sure the JFR data is flushed to disk (ie. the repository path) – Klara May 18 '16 at 12:32

1 Answers1

0

I assume JDK 7/8, since it is 2018 and you are on WLS, which means recordings can only be dumped in the Java shutdown hook. Try SIGTERM

kill -l 15

In JDK 9 and later, a dump can also be written (in native) if the JVM crashes. The file is located where the Java process was started and is called hs_err_pidXXX.jfr

JDK 10 added support for Old Object Sample events, which can be used to diagnose memory leaks. If the application exits due to an OutOfMemoryError, it will write an OOS event with paths to GC roots (regardless if you have enabled the event or not). It should provide information to solve the memory leak.

JDK 11.03 or later contains a command line tool, which can be used to print the contents of a recording file.

$ jfr print --events OldObjectSample hs_oom_pidXXX.jfr

By looking at the allocationTime you can see when objects were allocated. Memory leaks are typically allocated through out the lifetime of the application, so if you ignore the early samples (static objects) and late samples (short-lived objects) you are likely to find a leaking object and its path to the GC root. Just follow the reference chain until you find a reference that should not be there.

Kire Haglin
  • 6,569
  • 22
  • 27