Generally, Snap*trc
files are used by support rather than by customers. They contain any tracepoint data held in memory at the time of the dump. They can be useful in some OOM cases to check whether, for example, the OOM occurred because of exhausting native memory. It seems you've already figured out how to format them and the resulting *trc.fmt
text file is just a set of trace points, so it's the same as analyzing any trace (which generally means you need to understand the code, and thus why Snap*trc
files tend to be limited to use by support). You can find a bit more info on Snap files here: https://publib.boulder.ibm.com/httpserv/cookbook/Troubleshooting-Troubleshooting_Java-Troubleshooting_IBM_Java.html#Troubleshooting-Troubleshooting_IBM_Java-Snap_Traces
With that said, generally, here's how I analyze OOMs:
- Look at the
1TISIGINFO
in the javacore*txt
file. This will tell you whether it's a Java OOM or a native OOM.
- If it's a Java OOM, then load the
core*dmp
file into the IBM Memory Analyzer Tool. Note that the other question you referenced says that you must run jextract
on the core*dmp
file to analyze it, and this is no longer the case with recent versions of Java - simply load the core*dmp
file into the IBM MAT tool.
- If it's a native OOM, then that gets more complicated, so you can post back here with details.
As always, you can also open a support case with IBM and they can help you with some of this analysis.