Splitting Flight Recorder Files

Flight recorder is most commonly used to dump the last few minutes of data. Either by doing a profiling recording for a minute or so, or by having a continuous recording which is later dumped when some anomaly was discovered using a monitoring tool, for example the JMC JMX console.

Sometimes though, people bring me enormous recordings. Now, enormous recordings are not handled well in JMC. Most of the time, JMC will discover that you are trying to open something that is too large, and prompt you for what subset of the recording you want to open. 

rl5di

Sometimes it is easier to simply split the recording into smaller recordings instead.

Here is a small tool that can be used for splitting flight recordings:

split.jar

Usage:

java -jar split.jar filename [targetSizePerFile in MiB (default 50)]

Note that the jfr file will be split along chunk boundaries using a best effort algorithm. The individual files will be as close to the specified target size as the chunk boundaries allow.

Let me know if you run into trouble! 🙂

8 Responses to "Splitting Flight Recorder Files"

  1. […] the Splitting Flight Recorder Files blog entry for more information on how to use the […]

  2. Pedro says:

    We actually use JFR for long-term performance analysis, let’s say record the events on the server while our 2-hour load run test is being executed. That gives us a whole lot of awesome metrics on our EJB, database, servlet, transactions, etc. It is quite impressive. And yes I need to open these 200MB JFR files in a machine with around 24 GB of RAM but it is ok because it gives us so much info to work with!

  3. Marcus says:

    Great to hear about your success! 🙂

  4. Sergei says:

    Hi Marcus,

    we have similar issue running our application on Linux.

    -XX:FlightRecorderOptions=defaultrecording=true,disk=true,repository=/u02/tst/Tier4/JFR/SOA1

    Go to the repository directory at the end of the day and you will see tens of files with a total size of about 1.5 Gig. They accumulate 1.5Gig per day.
    We expecting that only one file will be kept with the most recent jfr data and all of the others will be deleted.
    Why they keep growing and how to avoid this ?

  5. Marcus says:

    You should always limit the set of data retained by flight recorder. Either use maxsize or maxage to limit how much data is retained in the repo.

  6. ER says:

    I’m trying exactly that, to split a file, but get:

    Examining recording 3866_no_fix_2025-04-02_11-27-08_80e9391.jfr …
    Ignoring incomplete chunk at end of file
    Found 0 chunks.
    Average chunk size: NaN MiB
    Target size: 300 MiB
    Chunk aligned target size: NaN MiB
    No JFR chunks found in file.

  7. Marcus says:

    Hi!

    That little utility is now dated. You probably have a recording from a much more recent JVM. Now you can simply use the built in jfr command. Try running the following to learn more:
    jfr help disassemble

    Another variant that should work across various jfr versions and compression alternatives is to use the JMC core libraries like so:
    java org.openjdk.jmc.flightrecorder.util.SplitRecording <jfr file path> [<target size in MiB>]

    It will split according chunk boundaries by default, but can also try to keep the individual pieces to ~ target size (by going with multiple chunks per piece).

  8. Marcus says:

    You can easily open a jshell to play around with JMC core like so:
    https://github.com/thegreystone/jmc-jshell

Leave a Reply

Your email address will not be published. Required fields are marked *